Pricing

Why per-seat pricing gets expensive

Per-seat SaaS pricing looks cheap at ten people and strange at a hundred. Here's the mechanism, the behaviours it quietly encourages, and when a flat-cost alternative wins.

· 4 min read

Per-seat pricing is the most successful billing model in software, and it deserves to be: it's easy to understand, it scales revenue with customer size, and at the point of purchase it always looks reasonable. Ten seats at a low monthly figure is a rounding error, and that's exactly the number you evaluate.

The problem isn't that it's expensive. It's where the expense comes from — and what a per-head multiplier does to how a company behaves once it's in place.

The mechanism, in one sentence

Consider what a chat platform actually spends per user: some database rows, some storage, a websocket connection, a bit of search index. Now consider a 200-person company where forty people are heavy users, sixty are occasional, and a hundred check in twice a day. The infrastructure cost is dominated by the first group. The invoice is dominated by all two hundred.

That gap is not a scandal — it's how software companies fund product development, support and the security team you're glad exists. But it does mean the price you pay has less and less to do with the service you consume as you grow, and it's worth knowing which of those you're buying.

The compounding shape

Three multipliers stack, and each is individually reasonable:

  1. 1Headcount growth. You hire. The bill grows proportionally, whether or not the new people generate proportional value from the tool.
  2. 2Tier upgrades. You need one feature — SSO, an audit log, a retention policy — and the upgrade re-prices every seat, not just the seats that use it. This is the big one, and it's the step that surprises people.
  3. 3Tool count. Chat, docs, tickets, CI, design, CRM. Each is individually defensible per seat. Together they can add up to a per-employee software cost that would startle you if anyone ever added it up. Try adding it up.
10 people50 people100 people
Base plan at $10/seat/mo$1,200/yr$6,000/yr$12,000/yr
After a tier jump to $15$1,800/yr$9,000/yr$18,000/yr
Six tools averaging $12/seat$8,640/yr$43,200/yr$86,400/yr
Flat-cost self-hosted chat~$150/yr~$600/yr~$600/yr

Illustrative figures, not quotes from any specific vendor. The row that matters is the shape difference: three of these lines are functions of headcount and one is a function of load.

The behaviours it quietly encourages

This is the part that gets less attention than the arithmetic, and it's arguably more damaging.

Hesitating before adding someone

The contractor who'd benefit from being in #engineering for two weeks doesn't get added, because adding them is a purchase. Small friction, applied constantly, in the exact place where you want zero friction.

Seat archaeology

Somebody's job becomes auditing who's still using what. This is genuinely necessary under per-seat pricing and produces nothing of value — it's pure overhead created by the billing model.

Shadow accounts

Shared logins, a team account passed around, people working around the seat count. The security implications are exactly as bad as they sound, and the cause is a pricing model rather than carelessness.

Tier-driven architecture

The clearest sign it's shaping decisions: when you find yourself choosing a technical approach to avoid needing a feature that lives one tier up. That's the pricing model designing your systems, which is not what you hired anyone for.

When per-seat is genuinely the right deal

It would be daft to argue the model is always wrong. Per-seat pricing is a good buy when:

  • You're small and staying small. Ten seats forever is cheap, and the alternative costs hours you don't have.
  • You need the support relationship. A vendor with an SLA and a human on the other end is worth real money, and per-seat is how that gets funded.
  • Compliance requires a vendor. Sometimes the auditable third party is the product.
  • The tool is genuinely differentiated. If nothing else does the job, the pricing model is a detail.

The problem is that team chat fits none of those especially well. Chat is a commodity in the good sense — the category is mature, the feature sets have converged, and several excellent open source implementations exist. It's the last place where a per-head multiplier earns its keep.

What flat cost changes

Move to a tool priced on infrastructure — or not priced at all — and a set of small decisions stop being decisions:

  • Adding a contractor to a channel is adding them to a channel.
  • Nobody audits seats, because there are no seats.
  • The feature you need isn't in a tier, because there are no tiers.
  • Hiring plans and software budgets stop being coupled.
  • Renewal season loses one conversation.

The cost, stated fairly: with self-hosted software you're buying hours instead of seats, and hours are more expensive than most people account for. With free hosted software you're accepting a narrower feature set — Fluid, for example, has no huddles, no voice or video, no SSO/SAML and no native mobile apps. Neither of those is free lunch; they're a different lunch.

No seats to count. No tiers to jump.

Fluid Chat is $0 whether you self-host it or use the hosted version, for unlimited people, with every admin feature included.

The test worth running

Take your per-seat tools, multiply each by your headcount and by twelve, and add them up. Then look at that annual figure and ask, tool by tool, whether the value scales the way the bill does.

For your CRM it probably does — more salespeople genuinely means more value from a CRM. For the place where people say good morning and paste stack traces, the honest answer is usually no.

FAQ

Questions people actually ask.

Why is per-seat pricing so expensive as teams grow?

Because cost is tied to headcount while the underlying service cost tracks usage, and the two diverge quickly. Three multipliers compound: hiring adds seats, a tier upgrade needed for one feature re-prices every seat, and per-seat tools accumulate until per-employee software spend is a significant line item.

What is the alternative to per-seat pricing for team chat?

Flat-cost or infrastructure-priced options. Self-hosted open source chat costs whatever your server costs regardless of headcount, and some products — Fluid Chat among them — are $0 hosted with no seat count at all. The trade is staff time for self-hosting, or a narrower feature set for free hosted products.

When is per-seat pricing actually a good deal?

When you're small and staying small, when you need a support relationship with an SLA, when compliance requires an auditable vendor, or when the product is genuinely differentiated. Team chat fits none of those well, because the category is mature and several strong open source implementations exist.

Does per-seat pricing change how teams behave?

Yes, and usually not for the better. It creates hesitation about adding contractors and guests, generates ongoing seat-audit overhead, encourages shared logins, and sometimes pushes teams into technical decisions made to avoid needing a feature that sits one tier up.

Something not covered? Open an issue.

Stop budgeting your chat by headcount.

Fluid Chat has no seats, no tiers and no renewal. Start free in the browser, or run it on your own Postgres.