Should your SaaS company use usage-based pricing?

Should your SaaS company use usage-based pricing? 

Usage-based pricing (UBP) seems simple: customers only pay for what they use, so it’s fully transparent and clearly better for everyone, right? 

No. Usage-based pricing is great for infrastructure products where customer value scales with usage. But usage-based pricing can also be disastrous and cost you customers because your pricing isn’t predictable or creates usage anxiety.

Your pricing model also directly impacts how and when you make revenue. So UBP is a pricing decision, but also touches product, UX, and financial strategy. 

In this article, we’ll explore when usage-based pricing actually makes sense, when it backfires, and how to make sure your pricing model doesn’t quietly wreck your company’s cashflow.

What is usage-based pricing? 

You already know what usage-based pricing is: Charging your customers by metrics of consumption instead of a flat fee every month/year. But usage-based pricing isn’t binary. Unless you charge a subscription fee with unlimited usage, you’re doing usage-based pricing. 

There are a variety of models you could use: 

Pure-play usage-based pricing

Users pay the exact amount of usage they’ve consumed. The best example is the OpenAI API.

Subscription with overages

Includes usage at a regular cost, but each additional bit of usage is paid. A great example is Supabase's pricing:

Credit-based pricing

Users subscribe for monthly credits and top up top buy more. Or they can buy credit packages individually. Example from Relevance:

‍

After more than a decade of seat-based subscriptions taking over, there’s now a resurgence of usage-based pricing. The reason? AI.

Where usage-based pricing is popular (and why AI makes it grow)

UBP is most popular In infrastructure and AI products. And for good reason. In infrastructure, products like Twilio, Stripe, and Snowflake popularized the model by charging in direct proportion to value. 

-Twilio: per SMS sent

-Stripe: as a % of each transaction

-Snowflake: per second of compute

These feel fair because they check the boxes of when usage-based pricing works. For Stripe, it’s great that founders only need to pay when they make money. This is a principle of usage-based pricing: The metric you charge for needs to align with how your product creates value for customers. But it also works because these products are ingredients to other products, which means if you build with them and charge your users a subscription, you can capture a better margin.

For companies with high underlying costs like compute, storage and bandwidth though, UBP is as much a pricing model as a survival strategy: It’s not like most SaaS companies where enterprise customers generate 80-90% of the revenue, but don’t cost 80-90% more. 

In infrastructure, you need to pay your bills, so you need to charge customers for everything they use.

Usage-based pricing is also getting more popular in AI. That’s happening for a few reasons: 

-Inference costs are high and variable

-AI APIs are expensive and make your cost scale with usage

-You definitely can’t offer unlimited access without bleeding money

We’ve written about why seat-based pricing will slowly die, but the summary is that when you pay for each bit of usage, a single customer could theoretically bankrupt you. Before AI, you may have had infrastructure cost, but the cost of each individual bit of usage was so low that it wasn’t even worth calculating. 

In AI, this is changing. So companies are adapting by either charging for usage or by limiting usage using credits, rate limits and overages.

Here’s simple checklist for when you should price based on usage:

When usage-based pricing works best

UBP is a great fit when:

• You have an easy-to-measure usage unit. Things like API calls are easy to measure, but it’s much harder to imagine what usage metric something like Notion might charge for.
• Customers understand and can forecast usage: You’ve probably seen those posts of people being surprised by expensive AWS bills. If your customers have no idea how much of something they might use, they’re much less likely to sign up for a paid plan because they don’t know what cost to expect.
• Usage maps directly to value: With Twilio, the value is reaching their users/customers. This is why it makes sense for Twilio to charge by the message. This is different for, say, Mailchimp, where the value is having a marketing platform you don’t need to think about. 
• Your customers don’t mind monitoring pricing. Consumers won’t bother with a usage-based pricing model that’s so complex that they don’t know what they’ll pay.

This means usage-based pricing is great in industries like AI, telecom, infrastructure, DevTools, etc. But there are other times when usage-based pricing doesn’t work: 

When usage-based pricing doesn’t work (and which companies shouldn’t use it)

• Usage metrics are too gamable: If Notion charged by the page, customers would simply contort their usage so that they’d only be using one giant page. 
• The billable metric defeats the purpose: If BI tools billed per event, users would be incentivized to send the tool less data, which makes the product experience worse.
• Pricing needs to be predictable: If customers constantly worry about what they need to pay, their experience with your product gets worse. 
• Usage doesn’t scale with value: For some products, the point is that they’re around—not that you’ll constantly use them. You don’t get more value from Slack the more messages you send. The point is that you can contact your team instantly.
• Your customers are consumers/prosumers: Unless people do something for work, they don’t constantly want to think about how much they’re spending. Pricing is part of UX.
• Your cashflow is fragile: If you have recurring costs but your revenue is variable, you might end up in a capital crunch.
• You’re forcing UBP on something that generates value differently:If your app is collaborative, per-seat probably aligns better than per-action.

This means AI usually doesn’t work in productivity, collaboration and similar types of tools.

Why hybrid pricing is often the real answer

Many successful companies end up blending fixed and variable pricing with models we described above:

‍

• Flat fee + metered usage: e.g. $99/month + $0.01 per message
• Or per-seat + usage: e.g. $20/user/month + $10 per 1K API calls
• Or tiers with usage caps and overages: e.g. 10K events/month included, $5 per 1K overage

This has a few benefits: 

- Smoother cashflow

- Better onboarding experience

- Room to grow revenue with heavy users

A quick self-check before you choose UBP

Ask yourself:

‍

1. Is the usage unit clear and understandable?

2. Can customers estimate their monthly bill?

3. Does usage correlate tightly with perceived value?

4. Will this model create friction in sales or onboarding?

5. Do your internal costs and cashflow support usage-based collection?

‍

After you've decided on your (usage-based) or not, pricing model, you'll need a billing system. And if you want one that actually works for engineers (not against them) and doesn't charge you a revenue cut, book a demo with Lago.

‍

‍