Software Growth

Usage-based pricing

Usage-based pricing charges customers for what they actually consume, such as API calls, messages or gigabytes, instead of a fixed price per seat or plan.

With usage-based pricing the bill follows consumption. A customer who sends 40,000 emails pays more than one who sends 4,000. Twilio, AWS and Algolia built businesses on it, and plenty of newer products now use it for AI features where every request costs you real money.

How common is it?

Kyle Poyar reported in Growth Unhinged (November 2021, drawing on OpenView data) that 45% of SaaS companies used some form of usage-based pricing, up from 34% the year before. OpenView's definition was broad: it counted both pure pay-as-you-go products and subscription tiers built around usage allowances (source). That broad definition matters. Most "usage-based" products are really hybrids: a platform fee plus included usage, with overage above it.

Main variants

  • Pure pay-as-you-go. No base fee. You pay per unit consumed.
  • Subscription with allowance. A monthly plan includes a quantity, and extra use is billed at a unit rate. This is the most common form for small SaaS.
  • Prepaid credits. Customers buy a balance and draw it down. Canva's credit-style approach is one example Poyar mentions.
  • Graduated or volume tiers. The unit price drops as volume rises.

How to calculate a usage bill

Take a $49 plan that includes 10,000 emails, with extra emails at $0.004 each. A customer who sends 14,500 emails pays $49 + (4,500 x $0.004) = $67. A customer who sends 8,000 pays $49. Your revenue per account now moves with their volume, which is the point.

Why founders like it

  • It makes starting small easy, so the first purchase is low risk.
  • Revenue grows with customer success, without a renegotiation (expansion revenue built in).
  • It matches your costs when usage drives your infrastructure bill.

Why it bites

  • Unpredictable revenue. Forecasting MRR gets harder, because part of it floats with usage. Many teams report a committed floor separately.
  • Bill shock. Customers who cannot predict their bill hesitate or churn. Show live usage and send alerts as they approach limits.
  • Billing complexity. You need accurate metering, disputes handling and invoicing. Tools like Stripe's meters do the recording and invoicing, but you still own the definition of a billable event (Stripe docs).
  • Wrong unit. If the unit you meter is not one customers care about, you have picked the wrong value metric.

Usage-based vs per-seat

Seats are easy to forecast and sell, but they tax adding teammates and ignore how much value each person extracts. Usage ties price to value but trades away predictability. A common middle path is a seat or platform fee for the predictable part and usage for the part that scales. See per-seat pricing for the other side of the comparison.

For a small SaaS

Start with a plan that includes a generous allowance, and bill overage only above it. That keeps invoices predictable for most customers and still captures the heavy users who cost you the most. Add pure pay-as-you-go later if customers ask for it. Always cap or alert before a runaway bill, because one surprised customer can cost you more goodwill than the overage was worth.

Sources

Back to the SaaS glossary