Dev Corner is a behind the scenes look at what Schematic’s engineers are building and why. We share the technical decisions, unexpected challenges, and lessons learned along the way. It’s a window into how the platform evolves — one feature at a time.
Building Drop In Components with Cole
Cole has been with Schematic for a while now — long enough to leave his mark on one of the platform’s most visible (and most used) layers: our component system. He leads development on the embeddable UI elements that power Schematic’s checkout flows, pricing tables, usage meters, and more. In this post, we’ll walk through where components started, what Cole’s building now, and why delivering “simple” UI for billing is a surprisingly complex challenge.
What Are Components?
Schematic’s components let our customers build rich billing flows without writing billing code. That includes pricing tables, plan choosers, paywalls, usage meters, and more. Customers can use our drag and drop Component Builder to configure and embed hosted components. These can be dropped into an app or website with minimal configuration. The result: production-ready billing UIs that just work.
What Made It Tricky
“Even just pricing a single feature — there are so many different ways to do it.”
At first glance, displaying a usage meter or upgrade button might seem like a simple UI problem. But behind each of those components is a surprisingly complex pricing engine — and that complexity leaks into the frontend.
Every feature in Schematic can be priced differently: overages, prepaid credits, pay-as-you-go, even hybrid models. That means the same component might need to behave in dramatically different ways depending on how the underlying entitlement is configured.
Supporting that level of variation requires real architectural flexibility. Components need to be dynamic, aware of context, and resilient to backend changes — without turning into an unmaintainable tangle of conditionals.
“When you're a company, you may need to do one [pricing model], but when you're a platform, you need to do all of them.”
It’s not just about rendering buttons or showing usage bars. It’s about building components that can keep up as our customers evolve — adapting to new pricing models, feature packaging, and plan logic without requiring a full rewrite every time.
What’s Next
One of Cole’s next priorities is investing further in Schematic’s credit burndown model.
Today, customers can price features using prepaid credits — allocating a balance that burns down as usage accrues. But making that system feel intuitive requires more than just backend accuracy. It demands clear, responsive UI that helps teams understand where they stand, how fast they're burning through credits, and what happens next.
That means new components, new display patterns, and likely new abstractions to support the range of ways customers use credits in the wild.
“It’s worth spending the time to make it easier — because other engineers need to be able to [quickly] understand how it works.”
It’s a complex problem — but one that matches the way many modern teams want to sell. It’s the kind of work that turns complexity into leverage, and that’s where Cole thrives.
