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.
When Vlad joined Schematic, he brought firsthand billing scars from his own startup — where he’d stitched together entitlements, usage tracking, and Stripe from scratch. He’d done it the hard way, and came to Schematic to help build better tools for developers facing the same challenge. In this post, we walk through how we built overages — the technical challenges, the design decisions, and how it helps our customers unlock new revenue opportunities.
Overages let you include a set amount of usage in a base plan — then charge customers only when they go beyond that. It’s a way to keep things predictable for most users while still capturing revenue from power users. They’re especially useful for high-volume features like event tracking or API calls, where usage can vary widely between customers.
You’ll see this model more and more in modern SaaS. PostHog, for instance, includes generous limits in their base plans and charges for usage above that. It keeps the product accessible while letting revenue scale with usage.
"You don’t just build overages. You build the billing system behind them.”
You need real-time usage tracking that ties into your billing logic. That means reliably ingesting high volumes of events, ensuring none are dropped, and scaling with customer load — all while maintaining consistency across systems. You also need a way to define which events are billable, how they’re counted, and what they cost.
It’s not just a billing toggle. It’s infrastructure.
One of the hardest edge cases we hit was mid-cycle plan upgrades. When a customer switches plans, it’s easy to assume you can just swap out the pricing and move on — but usage tracking doesn’t always follow cleanly.
We found that usage data tied to the old plan could be silently dropped during the transition, leading to underreported usage and missed charges. Fixing it meant rewriting how we handle plan changes under the hood, ensuring usage data stays intact and consistently reflected in billing.
It was a subtle bug — but one that would have cost both us and our customers if we hadn’t caught it.
On the product side, Vlad is focused on expanding our credit burndown capabilities — a model where customers pre-purchase a block of credits, spend them flexibly, and automatically top up when they run low. It’s a popular approach for AI-native platforms like OpenAI, and increasingly requested by teams building usage-heavy products.
What excites him most technically is improving the reliability of our billing infrastructure. He’s investing in deeper, automated end-to-end testing across pricing models, plan transitions, and usage reporting — ensuring that the system behaves consistently, even under edge cases and scale. Because once billing is live, correctness isn’t optional.
