Runtime Monetization Is Infrastructure. We’ve Raised $6.5M to Build It.

Three years ago, we started Schematic with a conviction that B2B monetization was broken architecturally. 

The way companies connect what a customer has paid for to what they can actually do inside a product was held together with duct tape.

We spent two years building deep infrastructure to fix that. Then the market started moving and moving fast. 

The Shift

For most of the last decade, B2B software pricing was static, seat-based, predictable, and boring.

That era is over.

Software execution used to be deterministic: the same input produces the same output with predictably high gross margins. AI changes that. Software is now probabilistic. Variable outputs, variable costs, at runtime. A static seat license cannot price value correctly, and companies know it. In response, the industry is moving toward hybrid, usage-aware models: credits, metered limits, multi-product bundles, per-seat-plus-consumption. 

This is not just an AI company problem. Any company running multiple products, multiple GTM motions, or enterprise contracts alongside a self-serve tier is already living with this complexity. How we monetize our products has expanded, and the infrastructure we leverage has not kept pace.

Underneath all of that complexity, a problem began to emerge: entitlements.

What Your Billing Provider Actually Does

When pricing changes accelerated, a lot of companies looked at their billing provider and assumed it was the bottleneck. It is not.

Though some of them are better than others for metering and usage-based billing, Stripe, Recurly, Orb, Metronome Chargebee, Maxio are good billing platforms. They store the subscription record. They run retry logic. They generate the invoice. They support rev rec.

What they do not do is enforce access and application behavior 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. And in most companies, the answer lives in custom code.

If you’re an experienced CTO, you know that billing providers ask you to describe limits at the plan level and use webhooks to catch state changes. That sounds reasonable until you think about what it actually requires. Your system has to receive those webhooks, store that state, write enforcement logic into every feature, handle the edge cases, and maintain all of it every time pricing changes. That is not a configuration problem. That is a product you must now build and maintain permanently. 

There is a second layer to this problem that is less visible but just as consequential. Most companies are not dealing with one catalog. They are dealing with many. Their billing system has one version of what a customer is entitled to. Their CRM has another. Their CPQ has another. Internal databases have another. None of these systems actually enforce what has been sold inside the product. The result is that end-to-end orchestration across contracts, provisioning, usage, and in-app experience becomes impossible. Every system has a partial view. No system has the authoritative one.

What You Are Actually Building

If you decide to handle entitlements in-house, you are signing up for an infinite roadmap.

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. A customer admin panel so the success team can grant exceptions without filing engineering tickets. Billing UI: pricing pages, customer portals, checkout flows. Trial services. Enforcement checks wired individually into every feature.

That is not a one-time build. It is a permanent tax on engineering that competes directly with your product roadmap.

And the business cost is just as real. When entitlements live in code, your commercial team cannot move without engineering. They cannot change pricing, run a promotion, provision an enterprise plan, or apply an override without filing a ticket. One CTO we worked with described their billing sync service plainly: "It's a technology that no one really knows. Everyone's kind of scared of it." That is not a failure of the engineers who built it. It is what happens when you build something nobody can stop maintaining.

The downstream effects are easy to underestimate. When no single system owns the entitlement state, usage overages go unbilled, trial conversions get missed, enterprise customers sit on limits that should have triggered an expansion conversation months ago. This is not hypothetical revenue leakage. It is structural: when the system that enforces what customers can do is fragmented across systems and embedded in code, the business loses its ability to see whitespace and act on it. Churn risk and expansion opportunity both become invisible until it is too late.

A Different Architecture

Schematic takes a fundamentally different approach.

Most billing systems ask you to receive state changes via webhooks, store them, and build enforcement logic in-house. The state lives in your database, and keeping it current is your problem.

We believe monetization and customer state are ideally handled through a streaming architecture. When your app initializes, Schematic opens a WebSocket and pushes entitlement state directly into local memory. Your app reads from memory, not the network. Checks are sub-millisecond. There is no cache to manage, no TTL logic to write, no invalidation to debug.

Engineers instrument once, via a single entitlement check per feature. Everything behind that check: the plans, the limits, the packaging, the exceptions, lives in Schematic, controlled by business users and synced automatically to your billing provider. A change in Schematic propagates everywhere: the product, the billing system, the customer portal. The application code does not change.

One thing worth being explicit about: Schematic handles commercial entitlements, not authorization. If a feature is gated by role, org membership, or security policy, that logic belongs in your existing RBAC or IAM layer. Schematic sits alongside that, handling the monetization policy: what a customer's plan allows, how much of a resource they've consumed, and what happens at a limit. The two systems address different questions and are designed to coexist.

We give customers two deployment models depending on their availability requirements.

The first is persistent streaming with client-side caching. Your app maintains a WebSocket connection to Schematic. State is pushed to each client and cached locally. Because it is a push model, the cache is always current. No TTL management. This is how most of our customers run in production and it is sufficient for the vast majority of use cases.

The second is the Replicator. If you want an additional layer of resilience, you self-host a lightweight container that syncs entitlement state continuously into your own Redis instance inside your VPC. Your app reads from that Redis, so checks are always in-memory and never dependent on a live connection to Schematic. If Schematic ever goes down, your app keeps running on last known good state. Most customers start with option one. Larger enterprises with strict availability requirements tend to add the Replicator as a defensive measure.

Both options give you sub-millisecond evaluation. 

What the Business Actually Gets

When entitlement state is centralized and decoupled from code, the business gets a control plane it can actually use. An account executive can see that a strategic customer is at 90% of their usage limit and provision an overage exception without filing a ticket. A RevOps team can launch a promotional plan or modify a trial duration in minutes. A product manager can gate a new feature to a beta cohort, flip it to a paid tier, and adjust the limit, all without a deployment.

This is not a dashboard bolted onto a billing system. It is what becomes possible when the enforcement system and the billing policy is decoupled from the application code. The question "what is this customer allowed to do?" has one answer, in one place, and the people closest to the customer relationship can change it.

For teams running enterprise sales alongside a self-serve motion, this matters in ways that compound. Provisioning a custom plan for a strategic account used to mean a Jira ticket and a three-day wait. In Schematic, it is a configuration change. The deal closes faster. The customer experience is consistent. And engineering never touches it.

What This Looks Like in Practice: Plotly

When Plotly came to us, the business wanted to launch new AI products with credit-based pricing and had a full monetization roadmap ahead of them. The engineering path was clear: build and maintain a robust entitlements system alongside Stripe, or find another way.

Ben, their VP of Engineering, was attracted to the idea of not building and maintaining entitlements at all. Nathan, his counterpart in product, was attracted to the speed it would unlock: launching new products without waiting on billing infrastructure.

Plotly is not a simple case. They run a PLG motion at scale, with a mix of free, self-serve, and enterprise customers, and new AI products being monetized via credits layered on top of existing plans. The kind of complexity where a homegrown entitlements system quietly becomes the bottleneck for everything commercial.

They implemented Schematic in three weeks. From there, they launched and began monetizing two new AI products via credits in half the time they had originally budgeted. Five thousand users signed up on an AI plan launched through Schematic. They stayed on Stripe Billing, rather than migrating to a new billing provider, because Schematic gave them the monetization agility they needed.

Nathan described making a pricing change after launch: "Literally 10 minutes from idea to production."

But what happened next is the part we think matters most. Engineering and product bought Schematic to launch new pricing models without building entitlement infrastructure. And quickly, their sellers and account reps started using it too: managing customer lifecycle, applying exceptions, tracking usage, setting up alerts. Engineering shipped product. The business owned monetization. That clean division of labor is exactly what Schematic is designed to create.

Plotly is not an outlier. Across high-growth startups and scaling mid-market companies, we are seeing the same pattern: teams that have outgrown homegrown entitlements and need a faster path to monetization agility. Companies like Florence, Blackcloak, Sema4.ai, Uniqode, Flashnet, OneCrew, Fencer.dev, Appy.ai, Zep, and Pagos are all running on Schematic today. Different industries, different pricing models, different billing stacks. The common thread is that none of them wanted to be rate limited by homegrown entitlements infrastructure. 

The Stripe Partnership

Schematic was built natively on Stripe Billing, and we are deepening that partnership.

We are launching a native Stripe App that makes the Schematic integration tighter and more accessible for teams already in the Stripe ecosystem. Plotly is proof of the model: they came to us thinking Stripe might be the bottleneck, implemented Schematic on top, and stayed on Stripe. The two systems are complementary by design. Stripe handles invoicing and payments. Schematic handles runtime enforcement. Together, they give companies a monetization stack the business can actually control.

We are also expanding our billing integrations for customers running on other great billing providers who need flexibility as their infrastructure evolves. 

Why We Raised

We raised $6.5M, bringing total funding to over $12M, because the timing is right and the category is real. Our institutional investors are long-term minded and understand the shift in the market. They include S3Ventures, MHS Capital, Active Capital, NextView, and Ritual Capital. Our angel investors also include world-class operators who’ve lived and breathed the problems we’re solving, for example, the Founder/CEO of LaunchDarkly, the Founder/CTO of Crowdstrike, and the founder/ceo of Salesloft

Entitlements are emerging from two decades of homegrown tooling. Every company that has shipped a paid product has built some version of this. Most of them are still maintaining it. The cost is not just the system: it is the commercial pricing models they couldn't take action on, the plans they could not launch on the timeline the business needed, the monetizationl agility they traded away to keep something running that nobody really wants to touch.

Runtime monetization should be infrastructure. First-class, decoupled, and fast. The same way you would not hand-roll your authentication layer or your feature flagging system, you should not hand-roll the system that enforces what your customers paid for.

Engineering instruments one check per feature. The business owns everything behind it. Enforced at runtime, automatically.

That is Schematic. And we are just getting started.