Per-seat pricing — charge a fixed price per named user, per month — is still the default model most B2B SaaS products reach for first, and it's easy to see why: it's trivially easy to explain to a buyer, trivially easy to forecast revenue from, and it maps cleanly onto how enterprise procurement already thinks about software licensing. It's also increasingly recognized as a poor proxy for the value a product actually delivers, and understanding both halves of that is what determines whether it's the right model for a given product.
Why per-seat won by default
Per-seat pricing is simple for everyone in the sales conversation: the buyer can answer "how many people will use this" without a spreadsheet, the seller can quote a number instantly, and finance can multiply seats by price and get next quarter's forecast. It also has a built-in expansion motion — as a customer's team grows, seat count grows, and revenue grows with no separate pricing conversation needed. For products where usage genuinely scales with headcount (a project management tool, an internal wiki, most collaboration software), per-seat is a reasonable-enough proxy for value, since more people using the product roughly does correlate with more value delivered.
Because seat count doesn't fluctuate day to day the way usage does, per-seat pricing produces smoother, more predictable MRR than usage-based pricing — which matters a lot to a finance team building a forecast, and is a real reason enterprise-focused SaaS companies keep choosing it even when they know its downsides.
Where it breaks down
The core problem is that seats are a proxy for headcount, not for value delivered or usage — and the two diverge constantly. A per-seat price on a tool five people use daily and forty people use once a month charges those forty people the same as the five, which pushes customers toward sharing logins to avoid paying for rarely-used seats — reducing your own visible usage data and adoption metrics along with your revenue. It also creates a structural disincentive to grow adoption inside an account: a customer champion who wants to roll the tool out to a bigger team has to go justify a bigger bill to procurement, which is friction actively working against your own expansion revenue, not for it.
When customers share one login across a team to dodge per-seat costs, the instinct is often to lock it down with stricter session enforcement. That treats the symptom. The actual signal is that the price-to-value ratio for additional users is out of line with what those users get out of the product — the fix that sticks is usually a pricing change, not a stronger login wall.
The alternatives: usage-based and hybrid
Usage-based pricing charges for a unit that tracks actual value delivered — API calls, GB processed, workflow runs, active-user-days rather than named-user-seats. It aligns price with value much more tightly and removes the seat-sharing incentive entirely, but it makes revenue harder to forecast (both for the vendor and the customer, whose bill now varies month to month) and requires metering infrastructure that per-seat billing never needed. Most companies that move away from pure per-seat land on a hybrid: a base platform fee (often still per-seat, but for a smaller core set of users) plus usage-based charges for the parts of the product that scale independently of headcount — API volume, storage, compute-heavy features. The hybrid model keeps the forecastability of a seat-based base while letting the parts of the product that genuinely track usage bill on usage.
When per-seat still makes sense
Per-seat remains a reasonable default when usage genuinely tracks headcount closely, when the buyer persona strongly prefers predictable, easy-to-explain pricing (enterprise procurement, in particular, often prefers per-seat specifically because it's easy to budget against), or when the product's value is inherently per-person rather than per-transaction — a password manager, an email client, most personal productivity software. The mistake isn't using per-seat pricing; it's using it by default without checking whether the product's actual usage pattern matches the headcount assumption it's built on.
Wrapping up
Per-seat pricing wins on simplicity and forecastability, and loses when usage doesn't track headcount — which is most products past the ones where value is genuinely per-person. The fix isn't necessarily abandoning per-seat wholesale; it's checking whether the product's value scales with named users or with actual usage, and building a hybrid model when the answer is usage, rather than defaulting to per-seat because it's the model everyone already understands.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.