Pricing pattern
Usage-based pricing
Pay-per-unit (per API call, per request, per row, per GB). Buyer's bill scales with their usage; SaaS revenue scales with buyer's success. The dominant pattern for infrastructure SaaS post-2020. Works brilliantly when usage tracks value; backfires when it tracks unrelated cost.
Verified · editorial policy
TL;DR
As of , the short version is: Pay-per-unit (per API call, per request, per row, per GB). Buyer's bill scales with their usage; SaaS revenue scales with buyer's success. The dominant pattern for infrastructure SaaS post-2020. Works brilliantly when usage tracks value; backfires when it tracks unrelated cost.
Usage-based pricing TL;DR
- Pattern
- Usage-based pricing
- TL;DR
- Pay-per-unit (per API call, per request, per row, per GB). Buyer's bill scales with their usage; SaaS revenue scales with buyer's success. The dominant pattern for infrastructure SaaS post-2020. Works brilliantly when usage tracks value; backfires when it tracks unrelated cost.
- When it works
- When the usage metric tracks the buyer's value (API calls when the buyer's product depends on the API; transactions when the buyer is making money). When the buyer can self-serve start without committing to a budget upfront. When variance in usage is significant – customers who use 10x more pay 10x more, which is fair on both sides.
- When it backfires
- When the usage metric doesn't track value (charging per-GB on a tool the buyer can't control storage on). When usage spikes unexpectedly and bills surprise the buyer – trust collapses faster than any feature can recover. When the buyer's procurement process needs a predictable budget – usage-based pricing is impossible to forecast for them.
- Last verified
- May 20, 2026
The mechanics
No fixed seat fee (or a small one). The bulk of the price is a per-unit metric (per API call, per generated image, per stored GB, per AI token, per transaction). Volume tiers reduce per-unit cost at scale. Often a free tier with a usage cap to enable activation before the bill starts.
Where you see this in the wild
AWS / GCP / Azure
Reference implementation. Per-unit pricing across every dimension; volume discounts at scale.
Vercel
Per-function-invocation, per-bandwidth-GB, per-edge-request. Active CPU pricing model for Fluid Compute.
Twilio
Per SMS, per voice minute, per WhatsApp message. The canonical usage-based SaaS pricing model.
OpenAI / Anthropic
Per token in / per token out. Usage scales with workload; volume discounts via committed-use.
Stripe
Per successful charge (% + flat fee). Usage = the customer making money; alignment is structural.
Fit assessment
When it works
When the usage metric tracks the buyer's value (API calls when the buyer's product depends on the API; transactions when the buyer is making money). When the buyer can self-serve start without committing to a budget upfront. When variance in usage is significant – customers who use 10x more pay 10x more, which is fair on both sides.
When it backfires
When the usage metric doesn't track value (charging per-GB on a tool the buyer can't control storage on). When usage spikes unexpectedly and bills surprise the buyer – trust collapses faster than any feature can recover. When the buyer's procurement process needs a predictable budget – usage-based pricing is impossible to forecast for them.
The Brunson lens
Usage-based pricing is a Stack Slide built into the billing system. Each metric is a deliverable; the buyer sees the totals add up in real time. The risk is the inverse of Weak Belief: when the buyer doesn't trust the metric (or can't predict it), the per-unit price feels arbitrary. Strong usage-based pricing pages explain the unit, the rate, and a worked example of a typical month's bill.
Common implementation mistakes
- Choosing a usage metric the buyer can't control. Charging per GB stored when the tool autostores everything kills trust.
- No usage cap or alerts. Surprise $10,000 bills end relationships permanently regardless of how good the product is.
- Hiding the unit pricing behind a calculator. Buyers want a clear rate they can multiply against their estimated usage themselves.
- Free tier with a hidden trap (usage cap that triggers a sudden tier-up). Bait-and-switch feel destroys trust.
- Per-seat AND per-usage charges combined ('$X per seat plus $Y per call'). Hybrid pricing confuses procurement and slows enterprise sales.
Questions founders ask about usage-based pricing
Should I start usage-based or seat-based?
Seat-based is easier to forecast for buyers and easier to sell to enterprise. Usage-based aligns incentives better and scales with customer success. Most SaaS post-2020 start hybrid: small seat fee + usage-based metering, which keeps procurement happy and aligns incentives.
How do I prevent surprise bills?
Hard caps with explicit upgrade prompts (not silent overages). Usage alerts at 50%, 80%, 100% of the buyer's stated budget. Monthly projection emails so the buyer can see where they're trending. Surprise bills are the single biggest churn driver for usage-based SaaS.
Should I offer committed-use discounts?
Yes, for buyers above $X/month (where X is the threshold of your revenue concentration risk). Committed-use deals are 20 to 50% discount in exchange for 12-month commitment + minimum spend. They stabilize revenue and signal enterprise readiness.
Related Brunson terms
Now diagnose your own pricing page
Patterns are the structure. The free 90-second Launch Diagnostic checks whether your pricing page is being read as Wrong Person, Weak Offer, or Weak Belief – the upstream diagnosis that determines whether any pattern works.