Consumption-Based Pricing for SaaS: What to Know

Consumption-based pricing charges customers for what they use instead of how many seats they bought. An API platform charges per call, a data warehouse charges per compute credit, a messaging tool charges per message sent. No headcount math, no "true-up" call at renewal. Three out of five SaaS companies now run some form of it, either fully live or actively testing, and the adoption curve has nearly doubled over the last five years.¹

I should say upfront that Lago, the company I run, is a billing engine built for exactly this shift, so take the framing here with that in mind. But this piece isn't a pitch. It's the thing I wish someone had handed me before we started fielding "how do we actually do this" conversations with founders who'd already decided consumption pricing was right and had no idea what it would cost them operationally to get there.

What is consumption-based pricing?

It's a model where the price scales with a measurable unit of usage, API calls, gigabytes processed, messages sent, active workflows, rather than with a fixed monthly fee tied to the number of people on a plan. Twilio charges per message and per call. Snowflake charges per compute credit. AWS charges per resource-hour. None of them ask how many people at your company are looking at the dashboard. It's the same logic behind pay-as-you-go pricing more broadly: you pay for what you actually consume.

The mechanical difference sounds small until you sit with it. A 100-person company running your product lightly pays less than a 10-person team hammering it all day. Per-seat pricing can't do that. It charges by headcount regardless of whether those 100 people touch the product once a month or fifty times a day.

Why per-seat pricing stopped working for everyone

Per-seat licensing has three specific failure modes, and they compound.

Enterprises buy more seats than they need because procurement rounds up, not because anyone's using them. That inflates your CAC on paper while doing nothing for actual usage. Second, and this is the one that stings if you're the vendor: you have no financial incentive to drive deeper usage once the seat is sold. Growth comes from selling more seats, not from customers getting more value out of the ones they have. Third, per-seat pricing quietly punishes your power users. The team running your product hardest pays the same as the team barely touching it, so there's no upside to becoming a heavier user, and there's no revenue signal telling you which features are actually driving outcomes.

Consumption pricing flips all three. Customers pay for what they use, you make more money when they get more value, and there's no artificial ceiling stopping someone from using your product twice as hard tomorrow as they did today.

a16z has a useful filter for when this actually applies: usage-based pricing tends to work best when your end user is other software, not a person.² Software has no natural aversion to metered costs the way humans do. It doesn't resent being "nickel-and-dimed," because there's no ego in the loop, just a system optimizing against a budget. Human end users behave differently. They resist monitoring their own consumption, and they build genuine resentment toward vendors who make them do it. This is why API platforms and infrastructure tools adopted usage pricing first, and why HR software mostly hasn't.

How fast is this actually moving

The numbers move in one direction, but not identically depending on who's counting. OpenView puts current adoption at three out of five SaaS companies running some form of usage-based or hybrid pricing, with 15% having gone largely usage-based or pay-as-you-go and 46% running a hybrid of base fee plus usage.¹ Maxio's 2025 pricing trends report puts overall usage/consumption adoption at 67%, up from 52% in 2022, a faster clip over a shorter window.³ The exact number depends on how you draw the line between "has some usage component" and "is primarily usage-priced," but both trend the same direction at a similar pace.

The part that should actually move a CFO: OpenView found that public usage-based SaaS companies grow revenue roughly 54% faster than the broader SaaS index and trade at close to a 50% revenue multiple premium.¹ Seven of the nine most recent SaaS IPOs with the best net dollar retention were usage-priced.¹ That's not proof usage pricing causes better retention on its own, plenty of confounding variables in there, but it's a strong enough correlation that public market investors have clearly priced it in.

Here's a quick way to see the tradeoffs side by side:

Most companies land in that last column, and I'll get to why.

What makes a consumption metric actually work

Not every usage signal makes a good billing metric, and this is where I've seen more implementations go sideways than any other part of the process. A good metric is measurable at scale without heroics, controllable by the customer through their own behavior, correlated with the value they're actually getting, and simple enough that a customer can look at their bill and understand why it says what it says.

API calls work well for developer tools because engineers can see the causal chain: more calls, more value extracted, more predictable cost. Per-gigabyte works for data platforms for the same reason. Per-message works for communications tools. What doesn't work: metering something like "feature toggles accessed" or granular internal user actions. They're too fine-grained, the customer can't reason about them, and the psychological effect is closer to being taxed than being billed fairly. If a customer can't explain why their bill went up, or can't do anything to bring it back down, the metric has failed regardless of how cleanly you can track it on the backend.

Most teams that get this right test two or three candidate metrics with early customers before locking one in. It's cheap to test and expensive to reverse once it's baked into contracts.

Should you add a base fee

Pure consumption, no base fee at all, removes the upfront budget conversation entirely, which is great for trial-to-paid conversion. It's also the fastest way to build a revenue line that whips around every month with no floor under it, and it lets a customer who's extracting real value pay almost nothing if their usage happens to stay low.

A hybrid model, a base tier plus usage on top, is what OpenView's data shows 46% of companies actually running, and it's not hard to see why.¹ The base covers your minimum cost to serve and gives finance a floor to forecast against. The usage component captures the upside when a customer actually scales. It's not a compromise so much as it's the version of consumption pricing built for a business that also has to answer to a board about next quarter's number.

Consumption pricing and NRR

This is the metric that makes founders' eyes light up when they first hear the pitch, so it's worth being precise about it. Consumption-based companies tend to post strong net revenue retention because usage compounds. A customer who succeeds with your product uses it more, which means they pay more, with zero incremental sales effort on your side. Landbot saw a 26% increase in NRR after moving to usage-based pricing, per OpenView's writeup, a concrete example of the mechanism actually playing out rather than a theoretical upside.¹

The mechanism cuts both ways, though, and I think this gets undersold in most pitches for the model. If a customer's usage drops to zero, so does their bill, immediately, with no contract floor holding revenue in place the way a seat-based annual contract would. Consumption pricing doesn't reward activation once at onboarding. It rewards activation continuously, forever, and it punishes any lapse in it just as fast. If you want the deeper mechanics of how this plays out across a cohort over time, Lago has a longer piece on usage-based pricing and NRR that's worth the extra ten minutes.

What you actually need to build

Three layers, and each one is more work than it looks like from a pricing deck.

Metering means capturing usage events in real time without adding latency to the product doing the thing being metered. This usually means event infrastructure, something like Kafka or a managed event queue, wired into your application code at every point that should generate a billable event. Billing means turning raw events into charges: applying the pricing model, handling proration, discounts, overages. Invoicing means turning charges into an actual bill a customer receives, on schedule, that they can dispute if something looks wrong.

Most teams start by bolting custom billing logic onto Stripe or Braintree, and for the first six months that's a completely reasonable choice. It stops being reasonable somewhere between "a few thousand events a day" and "enough volume that a bug in your aggregation logic costs real money before anyone notices." This is the part of the stack where a dedicated metering and billing layer earns its keep. Lago, being the one I know best, supports seven charge models out of the box, standard, graduated, package, percentage, volume, dynamic, and custom price, along with prepaid wallets and multi-entity billing, which collectively removes most of the months of engineering work that would otherwise go into a homegrown version of the same thing.⁴ It's also SOC 2 Type II certified, which matters more than it sounds like it should the moment you're trying to close an enterprise deal and their security team asks for your compliance paperwork before your AE has even finished the pitch.⁵

If you want the fuller comparison of how different charge models actually behave, the graduated pricing docs are a decent place to start, and this rundown of seven common billing models covers the rest.

Where this goes wrong

The most common mistake is choosing a metric that doesn't map to value, or that customers experience as unfair even if it technically does. Charging by API call works when the caller is a developer who understands what an API call is. It fails when the calls are invisible to the person actually paying the bill and they just see a number that goes up for reasons they can't audit themselves.

The second failure mode is launching without giving customers visibility into their own usage in real time. Nobody likes finding out they're over budget from an invoice instead of from a dashboard that warned them three days earlier. Bill shock isn't really about the number, it's about the surprise, and the fix is boring: usage dashboards, threshold alerts, and invoices that show exactly which events produced which charges.

Third, teams underestimate what metering at scale actually demands operationally. Events arrive late. Events arrive twice. Someone's clock is in the wrong timezone. Every one of those has to be handled deliberately or it becomes a customer dispute months later that nobody can reconstruct because the underlying data wasn't kept in a form anyone could audit.

Fourth: pure consumption with zero base fee, applied to a customer base that mostly uses your product lightly, tends to feel like being micro-charged rather than fairly billed. A thoughtful base tier heads this off before it becomes a churn reason.

Migrating without setting your NRR on fire

A hard cutover, moving every existing customer to the new model on a fixed date, is close to guaranteed to generate both churn and a wave of support tickets from people who feel ambushed. The transitions that hold up follow roughly the same shape every time.

Grandfather existing customers on their current pricing with a clear, generous sunset window, twelve to twenty-four months is common, so nobody feels rushed into a decision they haven't had time to model out. Show each customer, concretely, what they'd pay under the new model using their own actual usage data, not a hypothetical. Let new customers default to the new pricing immediately, which gives you a live population to validate the model and refine the metric before your entire base depends on getting it right. And communicate the change like you're explaining a decision, not defending one: here's why it benefits you, here's the math, here's who to talk to if the math looks wrong.

The teams that get this right tend to keep the overwhelming majority of their base through the transition. The ones that spring it on customers with a surprise invoice see meaningfully more churn in the following quarter. Neither outcome is a mystery once you look at how the rollout was handled.

FAQ

For sharper definitions of any term used above, Lago's pricing and billing glossary has the rest.

Is consumption-based pricing the same as usage-based pricing? Yes, the terms are used interchangeably. "Metered billing" is also common, especially in infrastructure and dev-tools contexts.

Does consumption pricing work for products with human end users? It can, but a16z's framing is a useful check: it tends to fit best when the end user is another piece of software, since software doesn't resent being metered the way people do.² For human-facing products, a hybrid model usually lands better than pure consumption.

What's the single biggest technical risk in building this yourself? Metering accuracy at scale. Deduplicating events, handling late arrivals, and keeping an auditable trail of what was billed and why is where most in-house systems accumulate the bugs that eventually become customer trust problems.

Should a new SaaS company launch with consumption pricing from day one? Only if the usage metric is already obvious and controllable by the customer. If you're still finding product-market fit, a simpler model buys you time to figure out what to meter before you commit customers to it contractually.

The part that doesn't fit in a pricing deck

Consumption pricing isn't a growth hack. It's an operating model change that touches your billing infrastructure, your sales motion, your finance forecasting, and the actual incentive structure between you and every customer you have. The companies doing it well aren't the ones that flipped a switch, they're the ones that treated the metric selection, the technical build, and the migration plan as three separate, sequential problems and gave each one the attention it needed before moving to the next.

If you're evaluating whether now's the time, the honest answer is: the infrastructure to do this well is far cheaper to buy than it was five years ago, the adoption data suggests the market has already made its decision, and the risk isn't in choosing consumption pricing, it's in choosing the wrong metric or rushing the migration. Get those two right and the rest is mostly plumbing.

Citations

1. OpenView, "Usage-Based Pricing: The Next Evolution in Software Pricing" — openviewpartners.com/usage-based-pricing/
2. a16z, "Usage-Based Pricing Is Popular, But Is It Right For You? Our Rule of Thumb" — a16z.com/usage-based-pricing-rule-of-thumb/
3. Maxio, "Consumption-Based Billing: The Ultimate Guide for SaaS Pricing Models" (2025 pricing trends report figure) — maxio.com/blog/consumption-based-billing
4. Lago charge models (standard, graduated, package, percentage, volume, dynamic, custom price) — getlago.com/docs/guide/plans/charges/charge-models/
5. Lago SOC 2 Type II certification — getlago.com/security