The quiet cost of per-seat pricing

A designer needs to look at one board. A contractor is joining for six weeks. A support person files three bugs a month and otherwise never opens the thing.

In each case somebody on the team pauses, works out what the seat costs, and decides. Usually the decision is fine. The problem is that the pause happens at all, and that it happens about a tool whose entire value proposition is that everyone can see the same thing.

The case for per-seat, honestly

Per-seat pricing is not a trick, and the version of this argument that treats it as one is not worth reading.

It has three real virtues. It lets a vendor charge a two-person team almost nothing and a two-hundred-person team a lot, which is roughly how the value distributes. It is legible — anyone can predict next month's bill without reading a pricing page twice. And it removes the cliff: you do not wake up one morning having crossed a threshold and doubled your cost.

Compare that to usage-based pricing, where nobody can forecast anything, or to tiered feature pricing, where the feature you need is always one tier up. Given those options, per-seat is a defensible default and it is the default for good reasons.

What it does anyway

The friction is not the price. It is that the price attaches to a decision you make constantly and would rather not think about.

Here is what per-seat actually produces on a small team, in roughly the order it appears:

1. Somebody has to approve seats. Not formally. But someone notices the invoice, so adding a person becomes a thing you mention rather than a thing you do.
2. Marginal people get left out. The contractor gets screenshots. The designer gets a Loom. The support person messages an engineer who files the bug on their behalf, translated and slightly wrong.
3. Then the tracker stops being the record. Because three of the people who know things about the work are not in it, and the real state of the project reassembles itself in chat, where nobody can query it.

That third step is the expensive one, and it does not look like a pricing problem when it arrives. It looks like a process problem.

The arithmetic, with real numbers

Take two published prices in this category, both from the vendors' own pages.

Linear's Basic plan is $10 per user per month billed yearly, and Business is $16 per user per month billed yearly (linear.app/pricing). Jira's paid plans are also priced per user; Atlassian notes that for annual subscriptions "you will be billed for the tier that most closely matches your user count" (atlassian.com).

At Basic, five people is $600 a year and fifteen is $1,800. Neither number is outrageous for a team that has fifteen people to pay. That is the point worth sitting with: per-seat pricing is rarely too expensive in total. It is that the total is a function of headcount, and headcount is the one variable you least want your tooling to have an opinion about. Every hire has a tooling cost attached across every per-seat tool you run, and while none of them individually changes a hiring decision, together they create a standing incentive to keep people out of systems.

It is worth being fair about free tiers, too. Linear's free plan carries unlimited members with a limit on teams and issues instead (linear.app/pricing) — which is a deliberate choice not to meter people, and a good one. Jira's free plan takes the other route and caps at 10 users (support.atlassian.com). The structure of a free tier tells you what the vendor thinks the scarce resource is.

Seats you are already not using

There is a second-order cost, which is that seats bought are not seats used. Zylo's 2026 SaaS Management Index, drawn from more than 40 million SaaS licences and $75 billion in spend under management, reports that organisations leave an average of 36% of their licences unused when measured against recommended utilisation levels (zylo.com).

That is enterprise data and it should not be transplanted onto a team of eight — a small team knows exactly who has a login. But it does describe the equilibrium per-seat pricing produces once nobody can see the whole list: you over-provision, then pay for it quietly for years. Small teams get the mirror image of the same problem. They under-provision on purpose, and pay for it in context that never makes it into the system of record.

Flat pricing is not free of trade-offs

The dishonest version of this argument ends here, with flat pricing as the obvious answer. It isn't, and the reason is arithmetic.

A flat price with an unbounded seat count charges a five-person team and a five-hundred-person org the same amount for very different value, which is not sustainable for the vendor and so does not stay flat for long. Every flat plan resolves this somehow. Basecamp resolves it with price: their per-user Pro plan is $15 per user billed monthly, and their flat Pro Unlimited plan is $299 a month billed annually (basecamp.com/pricing) — which means the flat plan is the cheaper option somewhere around twenty people and a considerably more expensive one below that. Flat pricing at scale is priced for scale.

The other way to resolve it is a cap: flat price, bounded seats, a number high enough that ordinary teams never meet it. That is a real limit and it should be stated as one rather than dressed up as "unlimited", because a customer who discovers the ceiling by hitting it has been misled regardless of what the pricing page said.

Neither resolution is a free lunch. The claim worth making is narrower than "flat is better": flat pricing moves the decision from who gets access to how big is the team, and the second question comes up far less often than the first.

What changes when the seat is free at the margin

Concretely, three things.

Adding someone becomes a five-second action rather than a small negotiation, so the contractor, the designer and the support person are simply in the tool. The tracker stays the record, because the people with information can put it there directly instead of relaying it.

Nobody audits seats. The recurring hour of working out who still needs a licence stops existing, along with the small unpleasantness of removing people.

And the bill stops tracking headcount, which means the tool stops being something you weigh against hiring. That is a small effect per tool and a noticeable one across a stack.

None of this is worth switching tools for on its own. Pricing model is a weak reason to move; the tool being wrong for the work is a strong one. But when you are choosing between things that would both do the job, it is worth knowing which one will make you think about seats.

Disclosure

We build an issue tracker, and we picked flat pricing, so this essay argues for our own model and should be read that way.

For completeness, since it is the specific thing being defended: Kevta's Free plan is $0 with 2 workspaces, 5 boards per workspace and 10 members per workspace. Pro is $10 a month per workspace — not per person — and raises those to 10 workspaces, 10 boards and 50 members. Fifty is a real ceiling, not a euphemism, and it is where we resolved the arithmetic above. You can cancel at any time and keep Pro until the end of the period you paid for, and dropping back to Free does not delete anything; only creating the next board or member waits until you are back under the cap. Kevta is in beta. The current numbers are on the pricing page, which is the version that counts if this post has gone stale.