Pricing model
Usage-based pricing model
Usage-based pricing charges by what the customer consumes — API calls, GB of data, emails sent, messages processed. It is the dominant developer-tools pricing model and increasingly common in AI products. Done well, it aligns customer cost with customer value.
Verified · editorial policy
How the model works
Customer pays per unit of consumption. Pricing can be pure usage ($X per 1,000 API calls) or hybrid (a base subscription plus usage above a threshold). Heavy users pay more; light users pay less.
Best for
Developer infrastructure (email APIs, payment processing, AI inference). Products where heavy customers genuinely cost more to serve. Products where value scales with usage (more emails sent = more business value to customer).
Worst for
Products where usage is hard to predict for the customer. Products where customers want predictable budgets. Products with low cost-per-customer that don't justify the operational complexity of metering.
Unit-economics implications
- Unit economics align: customer cost scales with customer value AND infrastructure cost.
- Revenue concentration risk — a few whale customers can produce most revenue.
- Customer-cost predictability is bad. Many enterprises require predictable billing; usage-based without a cap is a non-starter.
- Churn-by-decrease is invisible — customers can reduce usage without canceling, which feels like churn from a revenue perspective.
Common implementation mistakes
- No usage caps or alerts. Customers wake up to a $10,000 bill from a runaway script and refund-rage.
- Pure usage with no subscription base. Eliminates revenue predictability; investors and operators alike struggle to forecast.
- Per-unit prices that are too cheap to matter. Customers stop optimizing usage and your margins compress.
- Complicated metering customers cannot understand. If the customer cannot explain the bill, the relationship erodes.
Positioning trap to watch
Usage-based pricing on non-developer products often fails because the customer cannot predict their usage in advance. Marketing-team buyers want fixed costs; engineering buyers tolerate variable costs. Pricing model has to match buyer-team's budgeting style.
Pricing teardowns of products using this model
Frequently asked
- Should I offer a usage cap so customers can predict bills?
- Yes. Either soft caps (alerts at thresholds) or hard caps (service stops above limit). Most enterprise buyers require it. Indie buyers appreciate it. Pure no-cap usage-based works for hobbyist developer tools and almost nowhere else.
Other pricing models
Diagnose the page, then pick the model
Pricing model is downstream of positioning. The free diagnostic labels which Brunson failure mode your page hits; the right pricing model follows from the positioning.