The flat per-seat subscription defined a decade of SaaS growth. It's now quietly coming apart, and the pressure comes as much from the cost structure underneath modern software as from what buyers will accept.
For years the per-seat model was easy to reason about on both sides of the table. A buyer counted licenses, a vendor counted logins, and the relationship stayed predictable. But that predictability was always something of a fiction. Seats measure access, not value, and they reward vendors for gating features behind headcount rather than for the work the software actually does. As products absorb more automation, the gap between seats sold and value delivered has grown too wide to ignore.
Why the subscription is under pressure
Two forces are pushing SaaS away from the flat subscription at the same time.
The first is a demand-side argument that has been building for years. Buyers have grown tired of paying for seats that sit idle and for tiers that bundle features they never use. They want cost to track consumption, and ideally outcomes. When a product does more of the work on its own, the number of humans touching it is a poor proxy for the value being created.
The second force is newer and more mechanical. AI features carry a variable cost that vendors can't wish away. Every inference call, every long-context request, every retrieval step burns compute the vendor pays for on the way through. A flat monthly price assumes a roughly flat cost to serve, and that assumption breaks the moment a single power user generates many times the compute load of a light one. A vendor offering unlimited AI at a fixed price is either subsidizing heavy users out of margin or quietly degrading the experience to protect it. Neither lasts, which is why usage-based structures are spreading fastest in the products that lean hardest on inference.
What changes for buyers and builders
Usage-based and outcome-based pricing align cost with value, but the alignment cuts differently depending on where you sit.
For buyers
- Cost follows value. Your team pays for what it consumes, so a pilot stays cheap and spend grows only as adoption and results grow.
- Budget becomes harder to forecast. The same flexibility that makes entry cheap makes the annual number fuzzy. A finance team used to a fixed line item now faces a variable one, and a spike in usage can land as an unwelcome surprise.
- Incentives can misalign at the edges. If a vendor bills per action, your team has a quiet interest in efficiency that the vendor may not fully share.
For builders
- Better value alignment. Revenue expands with the account instead of stalling once seats are saturated, and the model rewards building features people genuinely use.
- Harder forecasting. Predictable recurring revenue is part of what makes SaaS attractive to operate and to finance. Usage introduces variance into the top line, not just the cost line.
- Metering complexity. You now have to measure consumption accurately, expose it clearly, bill on it reliably, and defend it when a customer disputes a line. Metering is real engineering work, not a billing afterthought.
Hybrid models are where most teams land
Pure usage-based pricing is rare in practice because it serves neither side well on its own. Buyers want a floor of predictability. Builders want a floor of committed revenue. The models settling into place tend to blend a stable base with a variable component.
- Platform fee plus usage. A recurring base secures access and baseline revenue, while consumption charges capture the variable cost and the upside. It's the most common compromise, and the easiest for both sides to reason about.
- Prepaid credits. Customers buy a pool of credits and draw them down as they consume. Credits smooth billing, give buyers a spending cap they can see, and give vendors cash up front.
- Committed use. The buyer commits to a minimum volume over a term in exchange for a better rate. They trade some flexibility for a discount, and the vendor gets a forecastable floor.
You see these structures most clearly in vertical SaaS, where a product tied to a specific workflow can meter the unit an industry already counts, and in the wave of AI copilots, where consumption and cost to serve move together closely enough that flat pricing was never a realistic option.
The pricing question is really a value-metric question. Before your team debates rates, decide what unit of value the software actually delivers, and whether that unit can be measured cleanly, agreed on by both sides, and defended on an invoice. Get the metric right and the model usually follows.
Choosing and negotiating a model
Whether your team is buying or building, a few principles keep the conversation grounded.
If your team is buying, ask how the meter is defined and where the edges are. Push for a floor on cost and a ceiling on surprise. That means negotiating spending caps, alerts before thresholds are crossed, and the ability to review consumption in near real time instead of at invoice time. Find out what happens to unused credits and how committed volumes roll over. And treat the value metric as negotiable, not just the rate.
If your team is building, resist the urge to meter everything. Pick a metric that customers accept as fair, one that correlates with the value they receive and also tracks your cost to serve. Make consumption visible inside the product, so a bill is never the first time a customer learns what they used. Offer a hybrid by default so buyers keep some predictability, and save pure usage for the components where variable cost genuinely demands it.
The subscription isn't disappearing so much as fragmenting into models that map more honestly onto how software creates and consumes value. Teams that treat pricing as a product decision, rather than a spreadsheet exercise bolted on at the end, will navigate the shift with far less friction. If your team is weighing how these models apply to its own roadmap, tell us what you are working on and we'll share what we are seeing.
Back to blog