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.
Coleman joined Schematic about a month ago, and he’s already hit the ground running. He’s been writing Go for over a decade and has worked across a range of infrastructure heavy systems, from web proxies to alerting platforms. This is his first time working in the pricing space — and it turns out, usage-based billing brings its own set of surprises.
In this post, we’ll walk through a new feature Coleman built: usage based triggers. We’ll cover what the feature does, how it works under the hood, and why it's more complex (and more useful) than it first appears.
Let’s say you want to know when a customer hits 80% of their monthly AI usage. Maybe you want to show a warning in-app, prompting them to upgrade. That’s exactly what usage triggers make possible.
Usage triggers let teams define usage thresholds and receive alerts, via webhook, when those thresholds are crossed. That alert can drive whatever action makes sense for your business: automatically email the customer with a usage warning, flag the account for a follow-up from sales, or add the company to a target list for beta testing new features. Behind the scenes, Schematic handles the complexity of tracking usage and triggering alerts, so you can focus on turning that data into timely, meaningful action.
“The numbers mean something different to every person, right?... That's a really tricky problem.”
Usage isn’t one size fits all. Some teams use these alerts to identify high value accounts, while others rely on them to proactively warn customers before they hit a hard limit. The same signal can drive very different strategies.
That makes assumptions dangerous. So we designed the system to be highly configurable — letting customers decide which features to track and when to be notified. The goal was to offer that flexibility without adding friction, keeping the interface and experience as simple as possible.
But the tricky part wasn’t just product flexibility — it was making sure the backend could scale with it. To avoid duplicate alerts, Coleman built a deduplication layer that tracks which alerts have been sent, per feature, per company. It’s the kind of complexity you take on intentionally — because getting it right is what makes the product feel simple on the outside.
And of course, doing all this in a brand new codebase made it even more fun.
Coleman’s just getting started. The next phase includes broader notification types and smarter alerting logic, backed by deeper investments in our event system to ensure reliability at scale.
The thing Coleman said that stuck with me? That he hadn’t realized how many teams need this kind of infrastructure until he started building it. That’s been a theme around here: pricing is one of those things everyone underestimates — until they try to do it well.
