The meter you don't see
When Salesforce launched in 1999 with a per-seat subscription, the pricing model was the argument as much as the software. A flat monthly fee per named user made the cost predictable and the contract terminable — a deliberate contrast to the perpetual licences and steep upfront fees that Oracle and SAP had built their businesses on. But the decision had a second-order effect that took years to become visible: every feature Salesforce built thereafter had to justify itself in terms of seats. Growth meant adding users. The incentive was to make the product so embedded in daily work that each new hire was a new licence, not to make it faster or leaner for the users who were already there.
Per-seat pricing rewards breadth. A vendor in that model wants its software in front of as many people inside a customer's organisation as possible, which is why CRM platforms that started with sales teams gradually acquired marketing modules, service desks, analytics layers and commerce connectors. None of those additions were driven purely by customer demand; they were driven by the need to expand the seat count. The product grows outward, not deeper, because depth serves the same number of invoiced users while breadth creates new ones.
Distribution in the 1980s: one program, one machine, one box.
Thraex picture desk
Consumption changes what gets built
Consumption-based pricing — charging by the API call, the compute hour, the row processed, the message sent — creates a different pressure entirely. The vendor's revenue rises when the customer uses more, so the product is designed to handle volume elegantly. Edgar F. Codd's relational model, published in 1970, had nothing to say about pricing; but the query optimisers that sit on top of it today are shaped partly by the fact that in a consumption model, an inefficient query is a cost the customer can see on the bill. That visibility forces a kind of engineering honesty that per-seat pricing does not.
Chronology
- 1970Codd's relational model published
- 1999Salesforce launches per-seat SaaS subscription model
- 2023UK Competition and Markets Authority cloud services market study published
It also changes what customers watch. A per-seat shop counts headcount. A consumption shop watches dashboards, throttles workloads at month-end and builds internal tooling to avoid triggering expensive operations. The monitoring layer becomes load-bearing. The practice of careful, month-end accounting that drives ERP systems is mirrored here at the infrastructure level: someone in every consumption-billed organisation becomes responsible for the spend curve, and vendors know it. Snowflake, Amazon Web Services and similar platforms publish detailed cost-management tooling not from generosity but because a customer who feels out of control of the bill is a customer who re-examines the contract.
What reaches the roadmap
The billing model's grip on the roadmap is real and documented. Features that deepen the experience for users who already hold a seat — personalisation, keyboard shortcuts, offline mode — tend to languish in per-seat products because they do not expand the licence count and they do not reduce churn enough to justify the engineering investment. Consumption vendors, by contrast, have historically under-invested in user experience precisely because their customers are engineers and DBAs who tolerate rough interfaces in exchange for raw capability.
The room the argument was actually about.
Thraex picture desk
Where the models collide is in hybrid pricing: a platform that charges per seat for access and per consumption for use. Salesforce's later Data Cloud product, Snowflake's marketplace layers and Microsoft Azure's enterprise agreements all mix the two, and the internal consequences are predictable — two product teams with diverging incentives, two sets of salespeople with different commission structures, and customers who are never entirely sure which lever to negotiate when the renewal comes. The UK's Competition and Markets Authority found in 2023 that pricing complexity in cloud services was itself a switching barrier, independent of any technical lock-in.
The code can be rewritten. The billing model tends to outlive it, because it is embedded in sales compensation, financial forecasting and the customer's own budget categories. Changing it is a company reorganisation, not a release.