A lot of companies reach the same conclusion before they call us. Their pricing is too slow to change. Experiments take months. Every packaging update requires an engineering sprint. The assumption is that the billing provider is the problem.
It is not.
The billing provider handles invoicing, payments, dunning, and fraud. It stores the subscription record. It generates the invoice. It runs the retry logic for failed payments. These are important jobs, and Stripe, Recurly, Orb, and Metronome do them well.
What they do not do is enforce access at runtime. They do not answer the question: does this customer, right now, have permission to use this feature, given their plan, their usage so far, and any exceptions their account team has applied? That question has to be answered somewhere. In most companies, the answer lives in custom code.
When you read a billing provider's documentation, you see webhooks. A customer upgrades their plan, and Sripe fires an event. Your system receives that event, updates its record of what the customer can access, and the feature gates reflect the change.
This works until it does not. Webhooks fail. Events arrive out of order. Your database schema for entitlement state needs to handle edge cases that were not in the original design. The cache needs invalidation logic. The admin panel your customer success team needs to bump a limit does not exist yet. Neither does the billing UI, the trial service, or the enforcement check wired into every feature.
By the time a company has built all of this, they have a system. It works. And it belongs to engineering permanently.
When a CTO decides to build and maintain entitlements in-house, the project is not one thing.
It is feature flags for each monetized capability. Webhook receivers to catch state changes from the billing provider. Retry logic and dead-letter queues for when those webhooks fail. A database schema to store entitlement state, with migration support as plans evolve. Cache invalidation logic so that access changes propagate correctly. A customer admin panel so that the success team can grant exceptions without filing engineering tickets. Billing UI: pricing pages, customer portals, checkout flows. Trial services covering trial start, trial end, conversion logic, and free tier management. Enforcement checks wired individually into every feature. Each of these is a real project. Each has to stay in sync with the others. Each grows more complex as the product grows.
One company we worked with had built a thoughtful entitlements system. Their engineers had made good architectural decisions. They had defined entitlements as a first-class concept, separated them from the billing layer, and wrapped their features in entitlement checks.
They also had a subscription synchronization service sitting between their product and their billing provider. It maintained a copy of subscription state, caught webhooks, and kept things in sync. Their CTO described it plainly: "It's a technology that no one really knows. Everyone's kind of scared of it."
That is not a criticism of the engineers who built it. It is what happens when you build something that nobody can stop maintaining. The system becomes the constraint. Every pricing experiment has to pass through it. Every new pricing model means changes to the sync service, the state schema, and the enforcement logic.
Their Chief Operating Officer described the downstream effect: every commercial initiative required reallocating engineering resources to support billing and monetization work. That was not a failure of operations. It was the natural result of an architecture where entitlements lived inside the application.
For a long time, pricing changes were infrequent enough that the cost of the in-house approach was manageable. Companies changed their pricing a few times a year. Engineering absorbed the work. It was slow, but survivable. AI is changing that. Companies launching AI features are not making annual pricing decisions. They are making weekly ones. What does a credit cost? How does it burn down? Should this model tier differently? What happens when a customer runs out mid-generation? These are not global pricing changes. They are operational decisions, and they need to move at the speed of product, not the speed of engineering tickets.
If your entitlements layer lives in application code and requires a deployment to change, you will not move at that speed. Stripe, Orb, and Metronome do not solve this. Runtime enforcement is not in their category.
Plotly was planning to move off Stripe. The assumption was that Stripe was the constraint. When they looked more carefully, the constraint was the entitlements layer: access logic living in the application, with no clean way for the business to change it without engineering.
Their VP of Engineering, Ben Postlethwaite, described what that path leads to: "Without Schematic, feature entitlements, limits, and access logic is just technical debt waiting to happen. It will constantly pull our team into billing work we shouldn't be doing. And I know it's slowing down product and sales."
Plotly implemented Schematic in about two and a half weeks. They then launched two new AI products with credit-based plans in half the time they had originally budgeted. Five thousand users signed up on an AI plan launched through Schematic. They stayed on Stripe.
After the implementation, Nathan Drezner from their product team described making a pricing change: "Literally 10 minutes from idea to production. What great validation of Schematic as a product."
The implementation decision was not to switch billing providers. It was to add a runtime enforcement layer on top of the one they already had.
Schematic sits between your application and your billing provider. Your application calls Schematic to check whether a customer has access to a feature, what their usage limit is, and how much they have consumed. Schematic evaluates the plan, the usage, and any overrides, and returns an allow or deny. It receives usage events from your application and routes them to your billing provider for invoicing.
One change in Schematic propagates everywhere. A change to a plan's entitlements updates access in the product, updates what gets billed, and updates what the customer sees in their portal. The application code does not change.
The checks are fast. With local SDK caching, flag checks run in single-digit milliseconds. With the Replicator, an enterprise deployment option that syncs entitlement state into your VPC, checks run from memory with no dependency on a live connection to Schematic. If Schematic goes down, your application continues running on the last known good state.
Most companies that contact us have already built the in-house system. They are not starting from scratch. They are asking whether they want to keep maintaining what they built, and whether the engineering capacity that maintenance consumes is worth more than what it would cost to replace it.
The answer depends on your company. But it is worth being clear-eyed about what you are maintaining. Not just the system itself, but the pricing experiments you have not run because they would require too much work, and the commercial agility you have traded away to keep something running that nobody really wants to touch.
If you want to see what the alternative looks like, [book a demo](https://schematic.com).
What is runtime enforcement?
Runtime enforcement is the access decision your application makes — often dozens of times per session — about whether a customer can use a feature. It has to account for their current plan, how much usage they've consumed, and any exceptions applied to their account. Billing providers don't make these decisions. Your application code does. And if you haven't built a clean layer for it, that logic is probably scattered across your codebase.
Why don't Stripe, Orb, or Metronome handle this?
It's outside their category. These tools are built around the payment and invoicing lifecycle. Runtime access decisions — checking limits, evaluating live usage, applying per-customer exceptions — are a different problem that lives inside your application, not in your billing provider. They're not competing products. They solve different things.
What's wrong with building entitlements in-house?
It works — until it doesn't. What starts as a few conditionals grows into webhook receivers, retry logic, dead-letter queues, database schemas, cache invalidation, customer admin panels, trial services, and enforcement checks scattered throughout your codebase. The real cost isn't the initial build. It's the permanent engineering responsibility you've taken on. One CTO described their company's billing sync service plainly: "It's a technology that no one really knows. Everyone's kind of scared of it."
Do I have to replace Stripe to use Schematic?
No. Schematic sits between your application and your billing provider. Plotly came to Schematic thinking Stripe was the bottleneck — and stayed on Stripe after implementing Schematic. Your billing provider handles invoicing and payments. Schematic handles runtime enforcement. They're complementary.
