How to Build a Modern Monetization Architecture: Lessons from the $1Bn Metronome-Stripe Acquisition

Stripe announced the acquisition in December 2025. Metronome was already billing usage for some of the largest AI companies, including OpenAI, Anthropic and Databricks.

The price got the headlines. The more useful question came from Anh-Tho Chuong, CEO of Lago, in her analysis Why Stripe paid $1B for Metronome instead of fixing Billing. Why would a company with thousands of engineers buy a capability that sits right next to a product it already owns?

Her answer is architectural. Stripe Billing launched in 2018 for the SaaS model of the day. Customers collected usage in their own systems, rolled it up into billing-ready totals, and pushed those totals to Stripe before the cycle closed. Usage was an add-on to a subscription, so that worked.

When usage becomes the business model, it stops working. By Lago's estimate, Stripe Billing tops out around 1,000 events per second, while an AI company at OpenAI's scale sustains 100,000 or more. Closing a 100x gap meant changing the data model under every existing integration. Stripe bought a company that had made different choices instead.

I agree with the conclusion and want to push it further. If a payments company with Stripe's resources could not retrofit a seat-era design, the licensing system inside your product will not stretch either.

The subscription and seat model rests on assumptions that held for twenty years. Usage changes slowly. One metric, users, describes value. Billing happens on a calendar. Anything variable can be counted later and summed.

Usage-based and AI pricing break each of these.

Ingestion. Seat systems receive a handful of state changes per customer per month: a seat added, a renewal, an upgrade. A usage system receives raw events from the product itself, continuously. Lago draws the line between synchronous HTTP request-response calls and asynchronous streaming from the source, and that is the right line to draw. An API built for occasional updates hits rate limits and timeouts long before it reaches AI-scale volume.

Aggregation. Pre-aggregation pushes the hard work upstream. If your billing system only accepts monthly totals, your engineers own the metering pipeline, the deduplication, the late-arriving events and every dispute about what the total should have been.

Timing. Calendar billing cannot invoice a customer the moment they cross a spend threshold mid-month, and it cannot decrement a prepaid credit balance in real time.

Dimensions. An AI feature might be priced on tokens, requests and compute at once, with different rates per model or region. A system that tracks one counter per subscription needs a workaround for each extra dimension.

Change rate. Seat pricing changed once a year. Usage pricing changes when your inference costs change, which might be monthly.

You can't patch these with features. They come from the core design.

Most B2B software companies don't run on Stripe Billing. They run on licensing, and that is where the Stripe lesson hits hardest.

FlexLM-era license managers were designed in the late 1980s for engineering software sold to companies with fixed workstation counts. Their job was to answer one question: may this seat run right now? A license file defines features and counts. A license server hands out concurrent tokens and takes them back. To change what a customer owns, you reissue the file.

Homegrown systems usually follow the same pattern with fewer guarantees. A signed key, a feature bitmask, maybe a phone-home check, and a spreadsheet that finance reconciles each quarter.

These systems do the job they were built for. They were never built to do the following.

• •

  capture every billable action as an event and stream it to a central service

• •

  aggregate consumption by account, feature and time window in near real time

• •

  price that consumption with rate cards that change without a release

• •

  enforce a usage cap or credit balance across a customer's whole estate

• •

  feed a billing system a clean, auditable usage record

Teams bolt usage onto these systems anyway. They scrape license-server logs, parse checkout data and build a reporting database on the side. The result is the same pre-aggregation trap Stripe faced, run by your own engineers, with numbers that arrive weeks after the usage happened.

If your current stack sells seats and annual subscriptions well, that is real value. It is also the reason it can't carry the next pricing model.

Before choosing tools, check any candidate architecture, including the one you run today, against five requirements.

Event-native ingestion. The system accepts raw usage events from the product and aggregates them itself. Your team should not maintain a metering pipeline upstream of billing.

Pricing as configuration. Rates, tiers, credit conversions and new usage dimensions change in a UI or API, and the product never redeploys. If a price change needs an engineering sprint, the architecture fails this test.

Runtime enforcement. When a customer hits a cap, exhausts credits or exceeds a contract term, the product knows immediately and acts on it.

Hybrid by default. Base subscriptions, seats, included credits, overages and pay-as-you-go run together in one offer. Most B2B vendors adopting new pricing land on a hybrid. Our guide to pricing options for modern SaaS and AI walks through each model and where it fits.

Billing and ERP independence. Usage and entitlement data flow to whichever CPQ, billing and ERP systems you use, and you can change those systems later without rebuilding your licensing.

Metronome passes the first two tests convincingly. That is why OpenAI chose it, and why Stripe paid what it paid. The last three are where B2B companies need to look harder.

Metronome was designed from the start around usage data streams. For an AI-native company selling API access through a cloud motion, that design is excellent. It meters, rates and produces invoices.

It is a billing-side platform. Usage flows in, and the output is what the customer owes. We explain the distinction in Two Architectures for Usage-Based Billing. Billing-side systems are strong at financial accuracy. They are not built to govern what a product does at runtime.

For a consumer product or a pure-cloud API business, that may be enough. B2B software companies with an installed base need two more capabilities.

Requirement one: entitlement control at runtime

Reporting tells you a customer used 140% of their commitment last month. Control stops usage at the limit, or allows it under the overage terms in that customer's contract, at the moment of use.

In B2B, usage defines feature access, capacity limits, contract compliance and upgrade triggers. Enterprise contracts include negotiated caps, exceptions, pooled credits across business units and mid-term amendments. When those rules live only in the billing system, product teams hard-code enforcement into the application. Every contract change becomes a code change, and the billing record and the product's behavior drift apart.

A product-side control plane reverses the order. The product checks entitlements before an action runs, contract terms apply instantly, and usage syncs to billing afterward. The product knows what the customer may do before an invoice exists.

Requirement two: legacy and future models on one platform

Most B2B vendors aren't greenfield. They carry perpetual licenses, node-locked desktop installs, on-premise servers, OEM bundles and hardware deployments, each with customers who pay on known terms. A large share of revenue, and most of the cash flow forecast, depends on those cohorts behaving predictably.

Some of those customers will never send usage events to a public cloud. Banks, government agencies, defense contractors and critical infrastructure operators run software offline, in dark sites or fully air-gapped. A licensing architecture that assumes an internet connection loses those accounts outright.

The real B2B question is how to add usage, credits and AI pricing for new cohorts while existing ones keep running untouched. A wholesale migration puts renewals at risk, retrains every rep, and swaps known revenue for revenue you hope to see. Two disconnected systems, one for legacy and one for usage, recreate the parallel-stack outcome Lago expects Stripe to end up with.

The Nalpeiron Growth Platform is built so old and new models share one control plane. The classifier is simple. Are you granting the right to run software, or access to a service?

Zentitle runs the installed estate. Licensing & Entitlements handles perpetual, subscription, node-locked, concurrent and feature-based licensing across SaaS, Desktop, Hardware and Air-Gapped On-Premise deployments. Offline activation and secure-environment support are part of the core design. Usage features run here too, at the entitlement level, so a desktop product can add a capped or burn-down metric without moving to a new system. See the licensing models Zentitle supports.

Zenmeter runs the usage future. The Monetization Engine is the native metering service inside the platform, built in from day one and sharing Zentitle's data model, identity and entitlement framework. Your product streams usage events in. Zenmeter groups consumption by account, feature, plan and time window, and rate cards translate it into charges. Token and credit models, pure pay-as-you-go and hybrid base-plus-usage plans run on the same engine, with per-user metering and dynamic rating. The technical detail is in Zenmeter: Native Usage Monetization. For AI features, token metering covers consumption billed by the token.

Zengain sits on top of both. Revenue Intelligence reads usage and entitlement data from either side and turns it into signals for sales and customer success: trial conversion, adoption, churn early warning, expansion and overage-to-upsell alerts.

The single pane of glass matters more than it sounds. Finance sees perpetual maintenance renewals and token overages in one place. Product managers change a rate card for one cohort while another cohort's licenses stay exactly as sold. Security teams audit one system and one database instead of three.

The platform is also ERP- and billing-agnostic. Nalpeiron controls the delivery of software rights: entitlements, activation, feature gating, usage counters and limit enforcement. Payment capture, invoicing and tax stay with your billing system or PSP, which Nalpeiron feeds. That can be Stripe, and it can be Metronome. The monetization control plane page shows how the pieces connect.

Scale is proven in practice. UiPath ran its licensing on Nalpeiron for ten years while it grew from start-up to over $1.2bn.

The goal is to add new models without disturbing the revenue you already count on.

Start by moving entitlements out of code. Whether today's system is FlexLM, a homegrown key generator or license logic scattered through the product, put existing licenses into Zentitle on the terms customers already have. Nothing changes for the customer. You gain one record of who owns what.

Next, pick one new cohort. An AI feature, a new cloud edition or a new market segment works well. Launch it on Zenmeter with a hybrid structure, such as a base subscription with included credits and metered overages. Hybrid pricing models keep the predictable base CFOs plan around while adding usage-driven upside.

Then watch the data before expanding. Zengain shows which accounts burn through credits, which never adopt, and where overages point to an upsell. Use that evidence to decide which legacy cohorts, if any, should move.

Finally, leave the rest alone. Air-gapped customers on perpetual licenses can stay where they are for as long as the business wants. On a shared control plane, coexistence is a supported, permanent state.

Stripe's choice reflects a rule every engineering team runs into. Early architectural decisions compound, and past a certain point changing them costs more than adopting a system built on different assumptions.

Software vendors face three options. Retrofit the license server or homegrown system to handle event streams, rating and runtime enforcement, which is the multi-year rewrite Stripe declined. Build a parallel usage stack beside it and accept two systems of record. Or adopt a platform that already runs both. Our buy-versus-build analysis breaks down the cost of each.

Metronome proved that usage streams need purpose-built infrastructure. B2B vendors should take that lesson and add their own constraints: runtime control, offline and secure deployments, and a legacy estate that must keep paying the bills while new models earn their place.