Someone on the team wants usage-based pricing shipped this quarter. Then an enterprise prospect says they can't sign a contract without a number they can budget, and the whole thing stalls. Both positions are correct, which is why the argument goes in circles.
The short version: charge for usage when value and cost rise together. Charge a subscription when value holds steady and your buyer needs a fixed number. When both are true, run both, which is where most AI and SaaS products end up.
What's the difference between usage-based and subscription pricing?
Subscription pricing charges a fixed recurring fee for access, regardless of consumption. Usage-based pricing charges for what a customer actually consumes, metered in units such as API calls, tokens, or compute seconds. That single difference drives everything downstream: revenue predictability, expansion behaviour, who your buyer is, and how much billing infrastructure you need.
Usage-based shows up as pure pay-as-you-go, tiered rates, volume pricing, or an included allowance with overages. AWS is the reference implementation, billing per second, per request, or per GB depending on the service.
Subscription shows up as flat rate, tiered plans, per seat, or per module. Slack is the familiar case: a published per user, per month rate, whether that person sends five messages or five hundred. The gap between the light user and the power user paying the same is where the dissatisfaction starts.
The four differences that decide most of it
Cost predictability. Subscription gives the buyer a number they can budget. Usage moves month to month and can produce a surprise invoice if nobody is watching the meter. Zylo's 2026 SaaS Management Index found that 78% of IT leaders reported unexpected charges tied to AI features or consumption-based pricing in the past year, and 61% cut projects because of unplanned SaaS cost increases. Bill shock kills deals the product had already won.
Value alignment. Usage-based ties cost to what the customer actually got. Subscription leaves light users paying for capacity they never touch.
Barrier to entry. Usage-based lets a customer start at almost nothing and grow into the bill. Subscription asks for commitment before the value is proven.
Revenue predictability. Subscription gives you steady recurring revenue that moves when you upsell. Usage revenue tracks customer activity, which is harder to forecast and expands without a new sale. Bessemer's State of the Cloud 2021 put usage-based companies roughly ten percentage points higher on net dollar retention than subscription-based peers, which is a dated benchmark but the direction has held.
| Parameter | Usage-based | Subscription |
|---|---|---|
| Charge structure | Variable, based on consumption | Fixed per billing period |
| Revenue predictability | Moves with customer activity | Steady and recurring |
| Revenue expansion | Grows as customers use more | Needs an upsell or a new seat |
| Barrier to entry | Low, start small and scale | Higher, commitment upfront |
| Implementation | Real-time metering, roll-ups, retry and refund handling | Plan tiers and access control |
| Technical requirement | A metering and rating layer, built or bought | Payment integration and webhooks |
| Buyer reaction | Feels fair, but variability worries finance | Feels safe, but light users resent it |
| Raising prices | Harder, customers watch every bill | Easier to grandfather and raise for new signups |
| Fits | APIs, inference, compute, developer tools | Workflow tools, steady-usage SaaS |
Six factors that place your product
Start with one fast filter: usage-based tends to fit products whose end user is other software, and subscription tends to fit products whose end user is a human. Software-to-software consumption grows without a natural ceiling and arrives with clean telemetry. A person can only watch so many videos, and charging them per action makes them hesitate before using the product.
That filter gets you an answer. The six factors below tell you how much to trust it.
1. Does value scale with usage, or plateau?
A gym charges the same whether you show up three times or thirty. An electricity bill tracks every unit. Software splits the same way.
Ask whether one more API call, workflow, or generated document creates more value for the customer or just more activity. Look at whether your heavy users six months in are clearly getting more out of the product than your light users. Check whether there's a natural ceiling on how much any one account can consume.
Value that climbs with activity points to usage. Value that plateaus after onboarding points to subscription.
2. Is there one clean metric you can meter?
Usage pricing needs a single unit that tracks value and can be measured reliably. If you can't name one, subscription is the more honest structure.
A workable metric correlates with the value different customers get, lets customers start small and scale, rises month over month for the average account, and is feasible to meter without inviting gaming.
Finding one is harder than it looks. A survey tool that charges per survey makes the customer hesitate before launching one. Charging per response is better aligned, except a response from a paying B2B customer is worth nothing like one from a free user. When no single unit is honest, mixing a subscription base with a usage fee usually beats forcing a bad metric.
3. Does your cost to serve rise with usage?
This is the factor AI teams feel most sharply, because model and compute costs move directly with token volume.
If gross margin shrinks when a customer doubles their usage, flat pricing quietly erodes your unit economics, and your most active account becomes your least profitable one. If marginal cost is near zero, flat pricing is safe.
4. Can customers predict their spend?
Usage pricing wins on fairness and loses on predictability, and lost predictability is what stalls deals.
Ask whether a customer could estimate next month's bill within a range they'd sign off on. Ask whether usage spikes unpredictably or follows a monthly pattern. Then ask whether you have caps, alerts, and a usage dashboard, because those are what make variable spend acceptable to a finance team.
Volatile usage points to usage-based only if you can ship the tools that make spend visible before it lands.
5. How does your buyer want to spend?
The mechanics can favour usage while the buyer still wants a fixed number, and the buyer usually wins.
A CFO signing a $50,000 annual contract knows what the year costs, and some will pay a premium for that certainty. A technical buyer optimizing spend wants the opposite and resents paying for capacity they don't use. If procurement requires a fixed contract number to approve the deal, that's your answer, or at least your floor.
6. How do your accounts grow?
Look at how your best accounts expanded in their first six months. This predicts the right model better than any framework.
Horizontal growth adds teammates, so value rises with participation and per-seat pricing fits. Vertical growth runs more workload on the same headcount, so two identical teams generate very different value and volume pricing fits. Dual growth does both, which is the textbook case for hybrid.
Run all six and a pattern shows up. Real conflict between them is itself the answer: if value scales with usage but your buyer needs certainty, or your cost to serve climbs while usage is spiky, that tension is what hybrid resolves.
The infrastructure question that comes first
Before committing to usage-based pricing, answer this: can you meter what customers use, accurately and in real time? If you can't, the model will hurt you regardless of how well it fits on paper.
Usage billing needs more than a payment gateway. It needs an ingestion path that reliably captures events, aggregation that rolls thousands of raw events into one correct total per period, rating logic for tiers, minimums, and overages, and a usage breakdown a customer can check against their own logs.
Idempotency matters more than it sounds. If the same event arrives twice because a network or SDK retried, the system has to count it once. Otherwise every retry is a double charge on a customer's invoice, and you find out when they email you.
{
"event_name": "api.calls",
"external_customer_id": "cust_123",
"event_id": "req_7f31c9",
"properties": { "endpoint": "/v1/generate" },
"timestamp": "2026-07-17T10:22:31.004Z"
}
The event_id is the whole defence. A stable identifier from the emitter means the retry resolves to the same billable event. Sending Events covers the contract, and Validating Events covers checking what landed.
Simplismart reclaimed 30% of daily engineering bandwidth after moving billing to Flexprice rather than running metering as a second product. If you can't meter accurately yet, subscription is the honest call until the infrastructure catches up.
Why most teams end up hybrid
A hybrid model pairs a subscription base with usage on top. The customer gets a predictable floor, and revenue still grows with consumption.
A typical shape: $50 a month for platform access plus an allotment of credits, then a per-unit charge for anything beyond it. It gives the seller a revenue floor and the buyer a fair marginal price at the same time.
Hybrid is common, not universal, and it's worth knowing which shape a product you admire actually runs. Twilio, for instance, is explicitly pay as you go with volume discounts and no contract, which is pure usage rather than hybrid. A base fee is something you add when you need the floor, not a default every consumption business lands on.
Hybrid is also the hardest shape to implement, because a single invoice has to carry a recurring charge, metered usage, credit drawdown, and proration on any mid-cycle change. Hybrid pricing works it through end to end on a Resend-style plan, and prepaid and promotional credits covers the wallet side.
Choosing without locking yourself in
Teams rarely get burned by picking the wrong model. They get burned by picking billing infrastructure that makes changing the model expensive, which turns a pricing decision into a migration decision.
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. Flexprice offers three deployment options, and all three run the same engine. Because it's open source and self-hostable, usage and revenue data can stay entirely inside your own infrastructure and never reach a vendor's cloud.
Practically, that means the pricing model is configuration rather than code: define the metric, instrument the event once, configure meters and rate cards for usage, subscription, or both, and let invoicing assemble the result. Changing your mind later is a config change rather than a rebuild.
Start from Event Ingestion if you want to test whether you can meter your product before deciding how to price it.
Top comments (0)