Per-seat software pricing is a tax on hiring

Here’s a business model that should annoy you more than it does. You pay software companies by the number of people you employ.

Not by how much you use the product. Not by the value it creates. By headcount. Hire a receptionist, add a seat. Take on three apprentices, add three seats, even if two of them touch the system twice a week. Grow the business the software is supposed to help you grow, and the software gets more expensive at exactly the moment you’re spending on wages, training and everything else.

Per-seat pricing is everywhere because it’s brilliant for the vendor. Their costs barely move when you add a user, but your bill climbs in a straight line. That gap is their margin, and it’s your growth being quietly taxed. Worth understanding before you sign the next three-year deal.

The maths nobody does until it hurts

Take a mid-range business tool at $60 per user per month. Feels fine at five people: $300 a month, $3,600 a year. You barely notice it next to rent and wages.

Now run the business forward. You’re doing well, so you grow.

• 5 users: $3,600 a year
• 15 users: $10,800 a year
• 30 users: $21,600 a year
• 50 users: $36,000 a year

Nothing about the software changed. It’s the same product doing the same job. You’re simply paying five figures a year now because you succeeded at the thing everyone told you to do. And that’s one tool. Most businesses run eight, ten, fifteen subscriptions, each with its own per-seat meter ticking over. Stack a CRM, a project tool, a comms platform, a document system, an accounting add-on, an HR tool, and you’re paying a per-head tax to half a dozen landlords at once.

The number that matters isn’t the monthly price on the pricing page. It’s the total, across every tool, multiplied by every person, compounding every time you hire. Almost nobody adds that up. The vendors are counting on it.

Seats you’re paying for and nobody’s sitting in

Before you worry about the price per seat, work out how many seats are dead.

Per-seat pricing has a nasty habit of billing for people who left, roles that changed, and staff who were provisioned “just in case” and never logged in. Because each seat is a small line item, nobody audits it. The subscription renews, the count creeps up, and you’re paying for a workforce that’s part ghost.

Run this exercise once a quarter. Pull the active-user report from each tool and compare it to who’s actually doing the work in it. Not who has a login. Who opened it in the last thirty days and did something. On most tools you can see this in the admin panel in about five minutes. The first time a business does it, the common result is somewhere between 15% and 30% of paid seats sitting idle. On a $36,000 tool, a quarter of it wasted is $9,000 a year buying nothing.

That’s not an argument against the software. It’s an argument against never looking. Reclaim the dead seats first, then judge the price on what you actually use.

When per-seat is honestly fine

This isn’t a case against subscriptions. For a lot of situations, paying per user is the right call, and building your own would be daft.

If a tool is genuinely central, used hard by everyone who has a seat, and maintained by a vendor who ships real improvements, per-seat can be excellent value. You get support, updates, security, integrations and someone else’s on-call team, all for a predictable line item. Accounting platforms, email, the core system your whole business lives in: these usually earn the money. Trying to build your own general-purpose accounting package to save on subscriptions is how you spend $200,000 to avoid spending $20,000.

The test is simple. Is the per-seat cost tracking the value each seat gets? If every user is a power user and the tool is doing heavy lifting, the meter is fair. The trouble starts when the meter and the value drift apart.

When per-seat quietly becomes the expensive option

Watch for these, because they’re where per-seat pricing turns from fair to a slow bleed.

Light users on full-price seats. You’ve got twenty people who need to see a schedule or submit a form once a week, and you’re paying full freight for each of them because the vendor only sells one tier of seat. You’re buying a Ferrari licence for someone who needs a bus ticket.

The tool is one workflow, not a platform. If the “software” is really just your quoting process, or your booking form, or an approvals flow with a login on top, and you’re paying per head for it forever, the arithmetic changes fast. A single focused workflow is often the cheapest thing to build and own outright.

You’ve outgrown the plan into “call us” territory. Notice how pricing pages show numbers up to a point, then switch to “Contact sales” for the tier you’re heading towards. That’s the tier where the meter comes off the published rate and onto whatever they think you’ll pay. Growth is the trigger.

The lock-in is doing the pricing’s job. Once your data, your integrations and your team’s habits are inside a tool, the renewal isn’t really a negotiation. The switching cost is the leash. If a vendor’s confidence in their renewals rests on how hard you are to leave rather than how much you like the product, you’re the one being farmed.

When two or three of these line up, “just pay the subscription” stops being the obviously cheaper choice. It’s worth doing the comparison properly instead of assuming build always loses.

Build versus subscribe, the honest version

Building your own software has a real cost, and pretending otherwise is how people get burned. You pay to build it, you pay to host it, and you pay to maintain it, because software that nobody maintains rots. Anyone who quotes you a build and goes quiet on the ongoing cost is selling you the fun part and hiding the rest.

But the shape of the two options is genuinely different, and that’s the point. A subscription is a line that climbs with every hire, forever, and never ends. A build is a lump up front and a smaller, flatter maintenance cost after. Somewhere on the graph, those two lines cross. Before the crossover, subscribe. After it, you’re paying rent on something you could have owned.

Where’s the crossover? It depends on the tool, the seat count, how fast you’re hiring and how central the workflow is. But a rough, honest way to sniff it out: take your annual per-seat spend on a specific tool, project it across the headcount you expect in three years, and compare that total to the cost of building and running the same focused workflow yourself. If the subscription’s three-year total is several times a build, and the tool is one workflow rather than a whole platform you’d never want to own, it’s at least worth a real quote instead of a renewal signature.

Often the answer is a mix. Keep the big platforms you’d be mad to rebuild. Replace the one or two expensive per-seat tools that are really just your own process wearing a vendor’s badge, and connect them back to the platforms you kept through their APIs. You’re not tearing everything down. You’re refusing to pay a growth tax on the pieces where the tax makes no sense.

What to actually do this quarter

You don’t need to blow up your software stack. You need to stop flying blind on it.

Pull every subscription into one list with its per-seat rate, its seat count and its annual total. Add it up, then project the total at the headcount you’re aiming for. Audit the dead seats and reclaim them. Then look hard at the two or three tools that are both expensive per head and narrow in what they do, and ask whether you’re subscribing to a platform or renting your own workflow back from someone.

For the ones that are really just your process with a login bolted on, get a build-and-run quote and put it next to the three-year subscription total. Sometimes the subscription still wins, and you renew with a clear head. Sometimes you realise you’ve been paying a tax on your own success, and there’s a better place for that money.

Either way, you’ll be deciding on the numbers instead of on the invoice you’ve stopped reading.