One account runs 50,000 API calls a month. Another runs 200. Both pay the same $499. The flat plan that made pricing simple at launch is now the reason margins on the first account are negative and the second account is quietly shopping around.
Moving to usage-based pricing fixes that arithmetic. The hard part is not the model. It is moving live customers off fixed plans, rewiring billing infrastructure, and keeping revenue steady while the layer underneath changes.
This is the sequence that works, and the technical decisions most migration guides skip.
Short answer
A subscription to usage migration runs in four phases: pick a value metric and model the revenue impact per customer before touching anything, build the metering and entitlement layer plus customer-facing usage visibility, realign sales comp and revenue recognition, then roll out through shadow billing, new customers, opt-in, and cohorts. Grandfather existing accounts for at least 12 months.
Is the product actually ready?
Four questions decide this, and three yes answers is the threshold.
Does value scale with usage? If a customer who uses the product ten times more gets roughly ten times more value, consumption pricing fits. That holds for most AI products. It holds much less for collaboration tools where value comes from network effects rather than volume.
Is there a metric you can measure in real time? It has to be trackable as events arrive, understandable to the customer, and tied to what they receive. API calls works for developer tools. Tokens processed works for LLM products. Documents generated works for productivity tools. No clear metric means no migration yet.
Are costs variable? If serving one customer a hundred times more costs meaningfully more in inference, compute, storage, or bandwidth, flat pricing is eroding margin on power users every month.
**Is current pricing creating friction? **The signals are customers asking for custom pricing, prospects balking at the top tier, power users churning while lighter users on the same plan get the better deal, and sales spending more time negotiating than demoing.
Phase 1: strategy
What is a value metric and why is it hard to change?
The value metric is the unit that represents how customers get value from the product. It is a one way door. Once customers are trained to think about the product in terms of a specific unit, changing it later costs trust and operational work. Packaging, tiers, and price points are all reversible. The metric is not.
Metrics fall into four categories. Inputs are data ingested, queries, or API calls. Usage covers sessions, compute hours, or processing time. Outputs are documents generated, reports created, workflows completed. Outcomes are time saved or costs avoided.
For most AI and SaaS products the workable range sits between usage and outputs. Pure input metrics like tokens consumed read as cosmetic to the buyer. Pure outcome metrics like revenue generated are hard to measure reliably. Something like documents processed or conversations resolved is measurable, visible, and correlated with value.
The AI-specific trap is charging for what drives your cost rather than what drives customer value. Your cost is GPU tokens. Your customer's value is tasks completed. Per-token billing makes a customer feel penalised every time they refine a prompt.
To validate, interview 10 to 15 customers across segments and ask what unit they would use to describe the value they get. Clustered answers mean you have the metric. Scattered answers mean more customer development first.
Which pricing architecture?
The choice is not subscription versus usage. It is where on the spectrum to land, and almost nobody lands on pure pay as you go. Companies using hybrid pricing report 21% median growth rates and 19% average revenue growth.
Four hybrid shapes hold up in production:
-Base plan plus overage. A flat monthly fee including a quota, then per unit beyond it. The gentlest path, because it still looks like a subscription to the buyer.
-Block-based capacity. Customers pre-purchase usage blocks instead of paying per unit in real time. Procurement gets a number to approve.
-Minimum commitment plus true-up. A committed floor at a discounted rate, per-unit charges above it. Standard in enterprise deals.
-Prepaid credits with drawdown. A pool of credits consumed across features, where one credit maps to ten API calls or one processed document. This normalises capabilities with very different unit costs into one currency the customer can reason about.
Credits are worth serious attention when a product spans several AI capabilities at different cost profiles. The customer thinks in credits while the backend maps credits to resource consumption. Flexprice handles that mapping through a wallet system with prepaid and promotional balances, expiry rules, and automatic top-ups when a balance crosses a threshold.
Model the revenue impact before anything is customer facing
Take every current customer's actual usage and calculate what they would pay under each candidate model. Sort into three buckets: pays more, pays roughly the same, pays less.
A healthy distribution is 60 to 70% of customers within 15% of current spend, 15 to 20% paying more (usually the power users who were being subsidised), and 10 to 15% paying less. If more than 30% see a significant increase, the grandfathering plan is not strong enough yet.
Model the trajectory rather than the snapshot. Usage revenue moves more month to month, and it usually shows higher net revenue retention because expansion happens without an upsell conversation. Then stress test the downside. If usage drops 20% across the board, what is the revenue floor? If pure usage revenue at 80% of current levels does not cover operations, the model needs a base fee.
Design grandfathering as a plan, not a promise
Four tiers, in order. New customers only for the first two to three months, which validates the model and the billing path under real conditions. Then opt-in migration for existing customers, with an incentive and a guarantee their price will not exceed the current plan for six months. Then cohort migration in waves, starting with customers who are currently overpaying, at 60 to 90 days notice per cohort. Then full migration, with the final holdouts price-locked for 12 months.
Cap annual increases at 15 to 20% for the first two years after migration. The target is zero churn caused by the pricing change itself.
Phase 2: infrastructure
Entitlements become dynamic
Under a subscription, entitlements are static. Pro plan, Pro features. Under usage pricing they move with consumption: 80% of quota triggers a warning, 100% triggers throttling, a block, or an overage charge.
Three types need configuring:
-Boolean. On or off by plan. SSO, priority support, advanced analytics. Usage does not affect them.
-Metered. Consumption tracked against a quota. API calls, tokens, storage, seats.
-Static. What is included without counting. Which models are available, which integrations are supported, which SLA applies.
Then pick an enforcement strategy for the moment a customer hits the limit. Soft overages let usage continue and bill later, which is smooth but carries credit risk. Hard limits protect margin and frustrate customers mid-task. Throttling degrades gradually. Prepaid top-ups prompt the customer to buy more before continuing.
Criticality decides it. Production infrastructure should not stop because a quota expired, so soft overages usually win. A tool the user drives directly is better served by top-ups, which give the buyer control of spend. Flexprice supports all three entitlement types through entitlement grants and configurable enforcement.
Build usage visibility before you switch pricing
If customers cannot see what they are charged for, they do not trust the invoice. Four things are required: a real-time dashboard of current-period consumption against quota or balance, historical trends so cost is predictable, spend alerts at configurable thresholds, and an invoice that shows which events drove which charges.
The Unity runtime fee in 2023 is the reference case. The pricing change shipped without tools for developers to predict or control what they would owe. The problem was not consumption pricing. It was consumption pricing with no cost transparency.
Build the dashboard first. Spend alerts and threshold notifications are the part customers notice when they are missing.
Phase 3: the organisation
Sales comp was built for bookings. Under usage pricing, revenue arrives as customers consume, so a comp plan that pays only on initial contract value gives the best reps a direct reason to resist the new model. Pay on account growth over time, add accelerators past the initial commitment, and penalise reps whose accounts consistently use under half of what they committed.
Customer Success shifts from churn prevention to revenue. Usage telemetry shows declining accounts and accelerating ones. Helping a customer find a new use case now increases consumption, which increases revenue.
Finance needs new forecasting and an audit trail. Revenue recognition under ASC 606 happens as usage occurs rather than when the contract is signed, which removes deferred revenue on unused prepaid periods and demands accurate per-period usage data. Confirm the billing system produces that trail before the first quarterly close.
Phase 4: rollout
Run shadow billing for one to two months first. Calculate what every customer would pay under the new model without charging differently. This surfaces the edge cases while they are still free.
Then new signups only for two months, watching conversion and expansion. Then opt-in migration with incentives, tracked by segment. Then cohort waves from months seven to twelve, monitoring churn after each one.
Watch four metrics weekly. Net revenue retention, which usually dips before it improves. Expansion revenue as a share of total, where 20 to 30% from existing customer growth is a healthy usage model. Billing support tickets, where a spike means the transparency tooling is inadequate. And usage-to-revenue conversion, which is where metering leakage shows up.
Why the infrastructure choice outlasts the pricing choice
A pricing migration is a multi-year bet on a billing layer. A closed-source, vendor-hosted platform trades one kind of rigidity for another: the subscription model is no longer the constraint, the vendor's roadmap is.
The Stripe acquisition of Metronome makes the point concretely. A popular usage-based billing platform is now part of a payments company, and its users inherit that ecosystem. If flexibility across payment providers matters, that dependency has a price.
Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud. Compared with Metronome, Orb, and m3ter, which are closed source and vendor-hosted, Flexprice is open source and deploys inside your own VPC or on-prem, so usage and revenue data never has to leave your infrastructure. Compared with Stripe Billing, which is built around subscriptions and payments and is usually paired with a separate metering vendor for usage-based products, Flexprice is the metering and billing layer itself, and is not tied to any payment gateway.
Mistakes that repeat
Picking a metric that tracks your cost. Charging per token when the customer thinks in documents makes every invoice feel arbitrary.
Going from pure subscription to pure pay as you go in one step. Maximum customer anxiety and maximum revenue volatility, at the same time. Use a hybrid as the bridge.
Launching pricing before visibility. Customers churn on uncertainty, not on price.
Leaving sales comp alone. Reps will push customers toward the old model. Fix comp before rollout.
Hardcoding pricing in application code. Companies that do this regret it inside 18 months. A price change should be a config change, not a deploy.
Ignoring revenue recognition. Loop in finance and auditors before launch rather than after the first close.
Getting started
The metering layer is the part to prove first, because everything downstream depends on the events being right. The event ingestion overview covers the ingestion path and how raw events become billable usage, and the source is on GitHub if you would rather read the implementation than the description.
Top comments (0)