Should your SaaS company use usage-based pricing?

Updated July 2026

Usage-based pricing seems simple. Customers only pay for what they use, so it's fully transparent and clearly better for everyone, right?

No. And here's the thing nobody tells you when you start reading about this: usage-based pricing and consumption-based pricing are the same model wearing two different name tags. If you've read a vendor pitch deck that says "consumption-based" and a blog post that says "usage-based" and wondered if you were missing some subtlety, you weren't. There isn't one.

What matters more is that usage-based pricing is great for infrastructure products where customer value scales with usage, the same logic behind usage-based billing for marketplaces. It can also be disastrous and cost you customers, because your pricing isn't predictable or it creates what people in this space call usage anxiety: the feeling of not knowing what a bill is going to look like until it arrives.

Your pricing model also decides how and when you actually make revenue. API billing as usage-based monetization is the clearest example of that. So this is a pricing decision, sure, but it's also a product decision, a UX decision, and a financial strategy decision, all wearing the same trenchcoat.

Let's get into when usage-based pricing actually makes sense, when it backfires, and how to keep it from quietly wrecking your company's cashflow.

What is usage-based pricing (and consumption-based pricing, and are they different)

You already know the basic idea: charge customers by how much they consume instead of a flat fee every month or year. Consumption-based pricing is that same idea, just a term more common in infrastructure and data circles, versus "usage-based," which shows up more in SaaS and AI pricing pages. Same mechanism. Different rooms it gets said in.

Usage-based pricing isn't binary either. Unless you're charging a flat subscription with genuinely unlimited usage, you're already doing some form of it. There are a few flavors:

Pure-play usage-based pricing, where users pay the exact amount they've consumed. The OpenAI API is the textbook example.

Subscription with overages, where a regular fee includes a usage allocation and anything past that gets billed. Supabase's pricing works this way.

Credit-based pricing, where users buy monthly credits upfront and draw down, or top up as needed. Relevance AI runs on this model.

After more than a decade of seat-based subscriptions eating the SaaS pricing world, usage-based (or consumption-based, pick your poison) pricing is having a real resurgence. The reason is AI, and it's worth understanding exactly why.

Where this actually shows up, and why AI changed the math

Usage-based pricing has always lived in infrastructure. Twilio charges per SMS sent. Stripe charges a percentage of each transaction. Snowflake charges per second of compute. There's a pattern hiding in that list that's more useful than "these are all infrastructure companies": all three are ingredients other products get built on top of, not things a person sits down and opens directly. That's actually a decent rule of thumb for the whole category. Usage-based pricing tends to fit products whose end user is other software. Subscription pricing tends to fit products with a human on the other end, clicking around, forming habits, getting attached to a UI.

It also works for Stripe specifically because founders only pay when they're making money themselves. That's the underlying principle worth remembering: the metric you charge for needs to align with how your product creates value for customers. Get that wrong and everything downstream, the pricing page, the sales conversations, the finance team's forecasting, gets harder than it needs to be.

For companies with real underlying costs, compute, storage, bandwidth, usage-based pricing is less a growth lever and more a survival strategy. Most SaaS companies don't have this problem: enterprise customers might generate 80 to 90% of revenue without costing anywhere close to 80 to 90% more to serve. Infrastructure companies don't get that luxury. The bills come due regardless of who's paying you, so you charge for what people actually use.

AI has the same problem, just newer. Inference is expensive and variable. The APIs you're building on top of make your own costs scale with usage in ways a flat subscription can't absorb. Offer unlimited access and you're one enthusiastic power user away from a very bad month. We've written before about why seat-based pricing will slowly die, and the short version is: when you charge per unit, a single customer can theoretically bankrupt you if you're not careful. Before AI, that risk existed too, but the cost of each individual unit was so small it wasn't worth calculating. That's no longer true, and companies are adapting either by charging directly for usage or by boxing it in with credits, rate limits, and overages.

When it actually works

A few things need to be true at once. You need an easy-to-measure usage unit, something like API calls, which is both simple to track and easy to break down further with group-level usage metering if you need that granularity. Try to imagine what usage metric a tool like Notion would even charge on and you'll see how hard this constraint actually is.

Customers also need to be able to forecast their own usage. You've seen the horror stories about surprise AWS bills. If your customers can't estimate what they'll owe, a meaningful chunk of them won't sign up in the first place, because the uncertainty itself is the deterrent.

Usage has to map to value directly. Twilio's value is reaching people, so charging per message tracks. Mailchimp's value is having a marketing platform you don't have to think about, which is a completely different shape of value and doesn't map to a per-send charge the same way.

And your customers need to actually tolerate monitoring their own spend. Some don't, and forcing a usage-based model onto someone who just wants a bill they never think about is a losing fight.

Put those together and you get why usage-based (consumption-based, still the same thing) pricing thrives in AI, telecom, infrastructure, and DevTools. Cloud infrastructure specifically tends to layer on dimensional pricing as a usage-based pattern, charging across multiple usage axes at once rather than one.

When it doesn't

Flip any of those conditions and you get a warning sign. If usage metrics are too gamable, like charging Notion by the page, customers will just contort their behavior into one giant page and you've gained nothing. If the billable metric fights the product experience, billing a BI tool per event means users are incentivized to send it less data, which makes the tool worse at the thing it's supposed to do.

Predictability matters more than people give it credit for. If customers are constantly anxious about what they'll owe, that anxiety becomes part of how they experience your product, whether or not you wanted it to. Budget limits in usage-based billing exist specifically to manage this, and if you're not offering them, you're asking for churn you didn't need to have.

There's also the question of whether usage scales with value at all. Slack doesn't get more valuable to you the more messages you send. The point of Slack is that it's there, instantly, not that you're maximizing message throughput. Consumer and prosumer products run into the same wall: people doing something for fun don't want to track a meter the way people doing something for work will tolerate. And if your own cashflow is fragile, recurring costs but variable revenue, a usage-based model can turn a bad month into a capital crunch fast.

Sometimes the honest answer is that your product creates value in a way usage-based pricing structurally can't capture. Collaborative tools tend to align better with per-seat pricing than per-action, because the thing you're paying for is access for a team, not individual actions. This is most of why usage-based pricing struggles in productivity and collaboration tools specifically. It's not that the model is bad. It's that the value shape doesn't match.

Why hybrid is usually where you land

Most companies that get this right don't pick one pure model. They blend fixed and variable pricing: a flat fee plus metered usage (99 dollars a month plus a cent per message), a per-seat fee plus usage (20 dollars per user plus 10 dollars per thousand API calls), or tiers with included usage and overages (10,000 events included, 5 dollars per thousand after that), sometimes with freemium as the usage-based entry point to get people in the door.

OpenView's most recent survey put hybrid adoption at 41% of SaaS companies as of May 2026, down slightly from 46% back in 2023, still comfortably the most common approach among any company using usage-based pricing at all. The appeal isn't complicated: smoother cashflow than pure usage-based, a friendlier onboarding experience than a bill with no floor, and real room to capture more revenue from your heaviest users without punishing your lightest ones.

Before you commit

Ask yourself five things. Is the usage unit clear and understandable. Can customers estimate their own monthly bill without a spreadsheet. Does usage actually correlate with perceived value, or are you charging for something incidental. Will this model create friction in sales or onboarding that a flat fee wouldn't. And do your internal costs and cashflow actually support collecting revenue this way.

Once you've made the call, usage-based or not, the next step is implementing it in your billing system. For the fuller picture of what that system needs to handle once you're in production, metering, rating, revenue recognition, and where build-versus-buy actually breaks, there's a complete guide to usage-based billing systems.

And if you've already made the call and you're comparing vendors, here's how the six real usage-based billing platforms stack up, including which two just got bought by a payment processor and which didn't.

If you want a billing system that works for engineers instead of around them, and doesn't take a cut of your revenue, book a demo with Lago.