Pricing models
Per-seat, usage-based, and flat rate — and the one question that actually determines which fits
4 min read
Three pricing structures cover almost all of SaaS: per-seat (price scales with number of users — Salesforce, Slack, most collaboration tools), usage-based (price scales with consumption — API calls, compute, data processed; Twilio, Snowflake, most infrastructure tools), and flat-rate (one price regardless of usage or seats). A growing share of companies now blend more than one into a hybrid — a base subscription fee plus usage overages is the most common pattern. [Established] as a description of what exists in the market; the boundary between categories is a spectrum in practice, not three hard buckets.
The mechanism: pricing should track the customer's value metric
The question that actually determines which model fits isn't "which is more common" or "which do investors prefer" — it's: what is the unit of value the customer is actually getting, and does your price move with it? A project-management tool's value scales roughly with headcount using it — more people coordinating, more value delivered — which is why per-seat fits it naturally. An API or infrastructure tool's value scales with how much work it's doing for the customer, independent of headcount — a two-person startup and a fifty-person team might send the same volume of API calls — which is why usage-based fits better there. A tool whose value doesn't scale cleanly with either (a single-purpose utility used the same way regardless of team size) is where flat-rate fits, and where per-seat or usage-based pricing would either underprice a heavy user or overprice a light one relative to the value they're actually getting. [Established] as the underlying economic logic; this is standard value-based pricing reasoning applied specifically to subscription software, not a SaaS-specific invention.
Getting this mismatched is a real, common failure mode: per-seat pricing on a tool used constantly by two power users and rarely by ten nominal license-holders overcharges the customer relative to actual value delivered (inviting a downgrade or churn), while usage-based pricing on a tool whose value is really "having it available" rather than "using it more" creates unpredictable bills customers resent and finance teams resist approving.
What each model actually trades off
Per-seat gives you predictable revenue (you can forecast off headcount) and a familiar buying motion procurement teams understand, at the cost of a natural ceiling: revenue growth requires either more customers or more seats per customer, and it can create a perverse incentive for customers to under-license to save money, especially if the tool doesn't strictly require a login per active user.
Usage-based gives you revenue that grows automatically as customers get more value (and a natural land-and-expand motion — a small usage-based deal can grow into a large one without a renegotiation), at the cost of two real risks: unpredictable revenue for you to forecast against, and unpredictable bills that can create real customer anxiety or bill-shock churn if usage spikes unexpectedly.
Flat-rate gives you the simplest possible buying decision and the most predictable revenue per customer, at the cost of leaving money on the table with your heaviest users and potentially pricing out your lightest ones — it's the model most vulnerable to a customer base with genuinely different usage intensities.
The 2026 shift toward hybrid, and reading a vendor-interested source correctly
Chargebee's 2025 State of Recurring Revenue and Monetization survey reports that a majority of subscription businesses it surveyed are moving toward hybrid pricing (subscription-plus-usage), and that companies combining multiple pricing mechanisms were substantially more likely to report improved margins than companies on pure usage-based pricing alone. [Directional] — this is a real, disclosed billing-vendor survey with a stated sample, but Chargebee sells the billing infrastructure that makes hybrid pricing easier to implement, which is exactly the kind of commercial interest worth reading with the source in mind: the underlying pattern (hybrid pricing spreading, pure-usage pricing creating margin unpredictability) is corroborated by the general shape of the market and is plausible on the pure economics described above, but treat any specific percentage from this survey as one interested party's self-reported number, not an independently audited measurement.
How to actually choose
Start from the value-metric question above, not from what's trendy. If you genuinely can't identify a value metric that isn't headcount, per-seat is probably right and a hybrid model is solving a problem you don't have. If usage varies enormously across your customer base and tracks real infrastructure or processing cost you're absorbing, usage-based (or a hybrid with a usage-based component) protects your margin on your heaviest users without needing to raise everyone's price. If your product is genuinely flat-value regardless of scale, resist the pressure to add seat or usage pricing just because it's common — a mismatched pricing model doesn't just leave money on the table, it actively confuses what a customer thinks they're buying, which shows up later as unexplained churn.
Getting pricing right doesn't solve the harder problem underneath it, though: none of this matters if nobody ever sees the pricing page. The distribution problem is next, and it's the module most "how to start a SaaS" content skips past fastest.
Up next
The distribution problem
SaaS is harder to get initial distribution for than most business models — stated plainly, not oversold either direction
4 min