Flat pricing vs per-seat: how software pricing quietly punishes growing teams

The two models, stated plainly

Per-seat pricing charges you for each person with a login. Your bill is a function of headcount. It is the default across mainstream business software: Slack's published Indian price list, for example, shows its Pro plan at ₹245.25 per user per month billed annually, checked on 31 August 2026.

Flat pricing charges you for the thing being run — a clinic, a school, an outlet, a branch — regardless of how many people sign in to it. Your bill is a function of the size of your operation.

Both are defensible. They simply track different things, and the difference only becomes visible when one of those things grows and the other does not.

The arithmetic, done out loud

Take an illustrative clinic. It opens with 6 staff who need logins: two doctors, a receptionist, a nurse, a pharmacist and the owner. It grows. By the second year it has 10 people on the system; by the third, 14.

Vendor A charges an illustrative ₹900 per user per month. Vendor B charges an illustrative flat ₹6,000 per month per clinic, unlimited users. Compare them at three moments.

Over the full three years — twelve months at each headcount — the per-seat bill totals (6 + 10 + 14) × 12 × ₹900 = ₹324,000. The flat bill totals ₹6,000 × 36 = ₹216,000. The gap is ₹108,000, and the entire gap is created by hiring, which is the thing the business was trying to do.

Notice what the buyer saw at the moment of decision: per-seat was cheaper. It was cheaper on the day of the demo, cheaper in the comparison spreadsheet, and cheaper for the first eleven months. The model only reveals itself later, which is precisely why it is worth modelling before you sign rather than after.

The cost that never appears in the comparison

The bill is the visible half. The behavioural half is what per-seat pricing does to how people use the system.

• Shared logins. When a seat costs money, the part-time weekend receptionist uses somebody else's account. Your audit trail now attributes her actions to a person who was not there — and in a clinic or a school, an audit trail that lies is worse than none.
• Delayed onboarding. New staff wait weeks for a seat to be approved, and work around the system in the meantime. The workaround usually outlives the wait.
• People deliberately kept out. The accountant, the auditor, the owner's spouse who does the banking, the security guard who logs visitors: all the people whose access would make the data more complete are the first to be denied a seat.
• Seat administration. Somebody has to add, remove and true up seats, and somebody has to argue about the true-up invoice when a leaver was not deprovisioned in time.
• Annual commitments. Per-seat contracts are frequently annual and rarely adjust downward mid-term, so a seasonal business pays peak headcount all year.

If your pricing model makes a customer think twice about giving a staff member access to the system, the pricing model is now shaping the customer's operations. That is a strange thing for an invoice to do.

Where per-seat genuinely wins

This is not a one-sided argument, and any vendor telling you flat pricing is always better is selling rather than explaining.

• Small teams that intend to stay small. A three-person studio on the illustrative numbers above pays ₹2,700 a month per-seat against ₹6,000 flat. Flat pricing overcharges them, plainly.
• Software whose value really is per person. A design tool, a developer licence, a personal productivity app: the value scales with the individual using it, so the price reasonably does too.
• Starting cheap to prove a case. Per-seat lets you buy two seats, run a pilot and expand. Flat pricing usually asks for the whole operation on day one.
• Highly variable headcount at the low end. If you genuinely go from two users to six and back, per-seat can follow you down where a flat fee will not.

The honest rule of thumb: per-seat suits teams whose headcount is small and stable, or where each additional person genuinely gets individual value from the tool. Flat suits operations where the software runs the place and everybody in the place should be on it.

The third model nobody mentions until the contract

Commission pricing takes a percentage of what flows through the platform — fees collected, bookings taken, sales rung up. It is common in booking and marketplace software and it is the most expensive model of the three for anyone who succeeds.

On illustrative numbers again: a clinic billing AED 120,000 a month on a 2% commission pays AED 2,400 a month. Double the clinic's revenue and the software bill doubles too, without the software doing anything new. Commission pricing is the only model where getting better at your job increases your costs proportionally, forever.

Four models, one table

Five questions before you sign anything

• Model my bill at twice my current headcount and at half of it. Put both numbers in writing.
• Which roles need a paid seat and which do not? Read-only, admin, accountant and API access are the usual arguments.
• What happens mid-term if I add seats, and what happens if I remove them?
• What is billed on top of the licence — messaging, payment gateway fees, SMS, storage, implementation — and at whose rate?
• What is the renewal price, and what is the maximum it can rise by? A quiet uplift at renewal undoes any model comparison you did at the start.

Pricing models are not a moral question. They are a statement about what the vendor wants to grow with. Read the model, do the arithmetic for your own third year, and buy the one whose incentives point the same way yours do.