Usage-based pricing is four decisions in a trenchcoat: what you meter, what unit you charge for, how you structure the rate card, and how you handle commits and overages. I've seen many teams get one wrong and only discover it later - forcing a redesign.

Usually, a founder reads a Snowflake retrospective, a post from Tomasz Tunguz, maybe a board deck that has been leaked - and then someone decides "let's go usage-based" into a Notion doc and has the built-in AI design some principles. A few weeks later it finally goes live but you discover…. lots of issues…

Most of what I read on UBP today is consulting-flavoured, with ideas like "align pricing with value" or "optimise for customer success". I've been known to write that too, for full disclosure. Fine, but it can still be unhelpful when you're a few days from launch and need to decide whether the meter is the API call or the successful transaction.

The design problem is rooted in reality, so let's have a look at how to do it.

What usage-based pricing is, briefly

Usage-based pricing (UBP) is a model where customers pay for the volume of a product they actually consume, instead of a flat fee like a seat or a platform fee.

Commonly, the unit can be API calls (Twilio, OpenAI), gigabytes (Snowflake, Datadog), events processed (Segment), characters translated (DeepL), or any other measurable quantity tied to value.

Outcome-based often fits in usage-based, where the result is charged in the same way.

Usage can be metered per request, batched, or summarised at a period boundary. Then, the price can be linear, tiered, or volume-discounted. The contract can be pay-as-you-go, prepaid credits, or a committed minimum with overages.

That's quite a few units as the surface of usage-based, now let's look at the decisions:

What's the right meter?

The meter is the thing you count, so picking the wrong one means fighting your customers about whether the bill is fair for a long time.

What makes a good meter? I think there's four properties:

1. It correlates with value the customer receives. For example, Adyen charges per successful transaction, not per API call. Snowflake charges per second of compute, not per query. The customer's bill goes up exactly when their business goes up. When it doesn't correlate, the bill feels like paying an even bigger tax and customers churn (or worse, they negotiate it down to zero).

2. It correlates with your COGS (cost of goods). If you're an AI company, your inference cost is per-token. A flat per-request meter will ravage your gross margin the moment a customer sends very very long prompts. There was a story recently that consultancy spent $500m on tokens…

   

3. It's auditable. Both you and the customer need to be able to count it independently and arrive at the same number. If your finance team can't reconstruct yesterday's usage from raw events, your customers can't either, and that's the bill they'll dispute.

4. It's stable over time. The meter's definition shouldn't change every quarter. Customers build forecasts on it. If you redefine "active user" between Q2 and Q3, you've just burned your renewal cycle.

For most B2B products, the meter is either an event (an API call, a generated document, a workflow run) or a resource over time (compute-seconds, storage-GB-months, active users per month).

Pick one! Don't try two and hope the customer tries to understand which one is the dominant one…

Here's an example: Twilio could have charged per API call but instead they charge per delivered message. A customer who sends 10k and gets 9k delivered pays for 9k. The 1k that didn't deliver were Twilio's network problem. When the meter is honest and defensible, so is the bill.

Snowflake could have charged per query or per data loaded - which was the common thing to do. Instead, they charge per second of compute. A poorly-written query that scans the whole table costs more than one that hits an index. The meter aligns customer behaviour with Snowflake's COGS. (Meter design as competitive lever. Most teams discover the lever only after shipping the wrong meter.)

What's the rate card?

The rate card is the price per unit of the meter.

The first question you should ask is: linear, tiered, or volume-discount?

Linear

Linear is simplest. For example, $0.01 per API call, no matter how many you do. Use it when your cost of goods is also linear and when your competitive landscape allows it.

(chart via BVP)

Tiered

Tiered means rates change at thresholds. First 100k calls free, next 1M at $0.02, anything above at $0.005. Tiered rate cards work when usage is heterogeneous (some customers do 5k/month, some do 5M) and when you want to acquire small customers at a low price point without losing margin on the large ones. Vercel runs tiered. Datadog runs tiered. AWS runs tiered with a thousand-page footnote.

Volume discounts

Volume discount is the SaaS-style continuation of tiered: same per-unit price, applied across all units once a threshold is crossed. Easier to explain to customers, harder to model internally. Pick whichever your customers will read.

A note on penny pricing, though: $0.0001 per token reads like an honest price. It also means your customer has to multiply by 10M to understand. Penny pricing creates emotional distance from the bill, which is great for adoption and terrible for trust at renewal. Round it. Bundle it. Don't manufacture units of consumption that customers can't reason about.

(chart via BVP)

How to structure commits and overages?

Most companies start with pay-as-you-go and graduate into commits as deals get bigger. The shape that works best:

The two failure modes to avoid:

1. Commits without rollover create the gift-card problem. The customer committed to 10M API calls/month, used 6M in January because they were ramping. By December they realized they'd been paying for 4M calls a month they never used. That's stranded value. They feel cheated. Renewal goes cold.

2. Overages priced too aggressively kill expansion. If your overage rate is 3x your committed rate, customers will hard-cap usage internally before they hit the commit, just to avoid the penalty. You've optimized your bill while suppressing your revenue.

Credits sit somewhere in between that shape… They're a prepaid balance of money or some other metric customers draw down against any meter, often with expiry rules. When done well they give flexibility (the customer can spend their 10M calls on whatever endpoint they need). When used sloppily they become "breakage" revenue and a finance audit liability.

Credits are an architectural decision, not a pricing model.

How do you migrate existing customers onto usage-based pricing?

This is the part nobody writes about because it's the hard part that requires you to communicate well, and understand what your customers value.

There isn't a playbook or template and you typically also can't just flip a switch.

Every customer on the old plan has a contract, a budget, and an expectation - if you surprise you lose renewal trust.

However, there is somewhat of a sequence you can follow that works:

1. Step 1: shadow billing. For 60-90 days, calculate what each customer would pay under the new model and put it on the invoice as a memo line. No financial impact. The customer can see what's coming. Finance can model the cohort impact before any contract changes.

2. Step 2: opt-in for new accounts only. Ship UBP as the default for net-new customers. Let the existing book run on the old terms. Product feedback without breaking anyone.

3. Step 3: voluntary migration with a sweetener. Offer existing customers a price-protection guarantee or a one-time credit grant to move. Some will. Most won't until step 4.

4. Step 4: forced migration at renewal. At contract renewal, the new model is the only option. By this point, you have 6-12 months of shadow data and customer references. The conversation is "here's your bill, here's the precedent, here's the upside on flexibility." Some customers churn. Plan for it.

This can still take a really long time. We've had customers whose migration migration took just a few days for the technical work and another 9 months for the contract rollover. That's the realistic shape, unfortunately.

What billing infrastructure has to handle

Usage-based pricing fails in production for boring reasons. Most are billing-infrastructure problems, not pricing problems.

The system has to ingest events at scale, deduplicate them, reconcile them to a customer, apply the right rate card, handle commits and overages without double-counting, and produce an invoice that a finance team can audit. Most teams glue this together from Stripe Billing, a metering service, a spreadsheet, and 4,000 lines of orchestration code. That code is now their actual billing system. It's fragile.

The infrastructure questions to ask before you ship usage-based pricing:

1. Can you compute usage per customer per meter per period in under a minute? If not, your monthly close will take a week.

2. Can your finance team audit any line item back to raw events? If not, you'll lose every dispute.

3. Can a customer self-serve a usage breakdown that matches the invoice exactly? If not, your support ticket volume is about to triple.

4. Can you change a rate card mid-cycle without rewriting historical invoices? If not, every pricing experiment becomes a six-week project.

Solvimon runs the metering, ledger, and rate-card engine as one system, so the infrastructure questions above stop being engineering problems. Different from gluing five tools together.

Frequently Asked Questions

What is usage-based pricing?

Usage-based pricing is a billing model where customers pay based on their actual consumption of a product (API calls, gigabytes, events, compute-seconds), rather than a flat subscription fee. Each meter is tracked and billed at a defined rate, often with tiered or volume discounts.

How is UBP different from hybrid pricing?

Pure UBP is consumption-only. Hybrid pricing combines a base subscription (or seats) with usage on top, often with credits or commits. Most companies that say "we do usage-based" actually run hybrid in practice, because flat usage-only pricing is unpredictable for both sides.

When should I avoid usage-based pricing?

When your cost of goods doesn't scale with the meter, when your customers value billing predictability over flexibility (most enterprise CFOs), or when your unit of consumption isn't legible to a non-technical buyer.

Can I run usage-based pricing on Stripe Billing?

Kinda - Stripe Billing supports basic metered usage but doesn't natively handle complex hybrid configurations (credits across meters, multi-entity, true-ups with proration).

How long does it take to design and ship UBP?

Designing the model takes a couple of weeks of focused work. Implementing it in production typically takes 4-12 weeks depending on existing billing complexity. The harder part is the customer communication when you migrate existing customers onto the new model.

What's the most common mistake teams make with UBP?

Picking a meter that doesn't correlate with cost of goods. The second most common is shipping a rate card with no commit structure, which makes revenue forecasting impossible.

How do I migrate existing customers without losing them?

Shadow billing for 60-90 days, opt-in for new accounts, voluntary migration with a sweetener, forced migration at renewal. Total elapsed time is typically 12-18 months. Skipping the shadow billing phase is the most common way to lose enterprise customers.

What's the difference between a meter and a rate card?

The meter is what you count (API calls, gigabytes, events). The rate card is what you charge per unit (linear, tiered, volume-discounted). One product can have multiple meters, each with its own rate card. Most legacy billing systems handle one rate card per customer at a time, which is why companies outgrow them.