Schematic's overage pricing lets customers exceed their monthly quota by paying per unit, like $1 per extra search. Hard limits cap total spend to prevent runaway costs. The API returns usage data so developers handle overages and standard usage the same way.
Chapters
Hello, I'm Ryan, a developer with Schematic, and I want to tell you about one of my favorite features that we just launched. In usage-based pricing, it's common to include, you know, 1,000 searches per month. But what if you want to let people go over that limit and charge them for every, you know, action they take past that limit to drive some incremental revenue, as well as let your power users use more of your product? We just launched overages. So we have a plan here called Pro, and it gives you 1,000 searches per month. But what if we want to let people go over that limit and pay for each search they use past 1,000. Now we can do that by changing this type to overages. So we set it up to sync to Stripe. We say you get 1,000 included like before, but now you can pay, now you can pay $1 per every unit used past an overage. So this is an overage, right? The first 1,000 are free, but once they go past 1,000, they can keep using the service, but it'll cost $1 every time. We've also added hard limits, and a hard limit is, is a way to protect both you and customers from runaway spend. So at $1,000, they'll start paying, but maybe we set a hard limit of $2,000, so we'll never let them use more than $2,000. I mean, that's both to protect you from maybe a bad actor, or potentially protect the customer. Maybe they automated this and accidentally used way more than they intended to. You know, at some point you'll stop them and you'll, you know, protect them. The best part about this is it's really easy to implement for a developer. Our API tells you for every given feature, its usage, its allocation, whether or not a user should be able to continue using the feature, and if we've exceeded the default plan usage. The cool part about this though is you can add in overage features along with the traditional usage-based features, and all developers need to do is check the same flags they were checking and the product will just work. So this way, on some plans, a feature might be normal, normal usage, and on other plans it could have an overage model. Without any changes necessary to the code. This is one of my favorite new features we've launched, cuz it's just one more way the schematic makes it easy to drive revenue with minimal developer effort. Thanks.
