The SaaS Trap: How Per-Seat Pricing Pushes You Toward Self-Hosting

There is a particular moment, familiar to anyone who has run a small team, where you log into a tool you’ve happily paid for for years, go to add a new colleague, and watch the price quietly leap by another tenner a month. Do it five times and the friendly little subscription has become a line on the budget that someone, eventually, is going to question. That moment is when otherwise sensible people start googling “self-hosted alternative to” — and per-seat pricing is the reason.

I want to be fair to SaaS here, because I’m not an evangelist who thinks everything must run on a Raspberry Pi in a cupboard. Hosted software is often the right call. But per-seat pricing has a specific, structural flaw that turns a good deal into a bad one as you grow, and it’s worth understanding why before you reach for the self-hosting hammer.

Why per-seat pricing feels like a trap

Per-seat pricing is beloved by vendors because it ties their revenue to your success. As your team grows, so does your bill — automatically, with no renegotiation. That’s brilliant for them and tolerable for you, right up until the value stops scaling with the seat count.

The trap is that the marginal user costs the vendor almost nothing, but costs you full price. Adding the fortieth user to a chat tool consumes a rounding error of server resources, yet you pay the same per-seat rate as the first. You aren’t paying for compute; you’re paying for growth itself. And the more occasional, read-only, or peripheral users you have — the contractor who logs in twice a month, the stakeholder who just wants to see a dashboard — the worse the deal gets, because each pays a full active-user price for a fraction of the value.

There is a second, subtler mechanism that makes the trap harder to escape once you are in it: switching cost. By the time the bill is large enough to hurt, your data, your integrations, your muscle memory and your team’s habits are all wound tightly around the tool. The vendor knows this. It is why prices tend to rise after you are embedded, not before, and why the “add a seat” button is always one click while the “export everything and leave” button, if it exists at all, is buried three menus deep and produces a CSV that fights you. Per-seat pricing is the visible cost; lock-in is the moat that stops you doing anything about it. Any serious plan to leave has to reckon with both.

It is also worth being precise about what kind of user hurts most, because it shapes the decision. A tool where every seat is a full-time power user genuinely extracting value is a defensible per-seat purchase. The pain concentrates in tools with a long tail of light users: the sales team’s twelve occasional viewers, the board members who log in once a quarter, the freelancers on a two-week contract. Vendors rarely offer a “read-only for a fiver” tier, because that tail is exactly where their easy margin lives. So the more your usage looks like a pyramid — a few heavy users, a broad base of light ones — the worse per-seat treats you, and the sooner the self-hosting question becomes serious.

The maths that tips the decision

Let’s make it concrete. Say a hosted tool charges £8 per user per month. Here’s how that scales against a self-hosted equivalent running on a modest £20/month VPS plus, generously, a few hours of your time:

At five users, SaaS wins comfortably — the convenience is basically free. Somewhere around fifteen to twenty users the lines cross, and beyond that the gap becomes absurd. The self-hosted cost barely moves because the bottleneck is rarely the server; it’s your attention, which is roughly fixed whether you have twenty users or two hundred.

What you’re really paying for at the crossover

When people justify SaaS at scale, they cite reliability, support, and “not being the on-call person at 2am.” Those are genuine and you should weight them honestly. But notice that none of them scale with seats either. The vendor’s uptime is the same whether you’re on five seats or five hundred. So if you’re being charged ten times more for the same reliability, you are, very specifically, paying a tax on the size of your team and getting nothing extra for it.

That’s the insight that makes self-hosting compelling at scale: the costs that genuinely justify a subscription are mostly fixed, while the price you’re charged is linear. The vendor has quietly decoupled what you pay from what it costs them to serve you.

It is worth naming the pricing tricks that grow out of this decoupling, because recognising them is half the defence. The “contact us for enterprise pricing” wall appears at exactly the seat count where the per-seat rate would start to look absurd on a public page — the linear cost is hidden the moment it becomes embarrassing. Annual-commitment discounts reward you for locking in before you have grown, capturing the future seats at today’s rate. And the classic move of gating a genuinely useful feature — SSO, audit logs, an admin API — behind a higher tier means you often are not even paying the headline per-seat rate; you are paying it plus a premium for the one feature a growing team actually needs. None of this is fraud. It is rational revenue design. But it all points the same way: the vendor’s incentives and yours diverge precisely as you scale, and that divergence is the trap the self-hosting question is really responding to.

What escaping actually looks like

The abstract argument is tidy; the reality is a docker-compose.yml and an evening. It helps to see how little separates a per-seat SaaS bill from its self-hosted twin, because the gap is smaller than the vendor would like you to believe. Most mature open-source alternatives are a single compose file plus a reverse proxy. A self-hosted team chat, for instance, is roughly this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

services:
  app:
    image: mattermost/mattermost-team-edition:latest
    restart: unless-stopped
    depends_on: [db]
    environment:
      MM_SQLSETTINGS_DRIVERNAME: postgres
      MM_SQLSETTINGS_DATASOURCE: "postgres://mm:${DB_PASS}@db:5432/mattermost?sslmode=disable"
    volumes:
      - ./data:/mattermost/data
    ports:
      - "127.0.0.1:8065:8065"   # bind to loopback; front with a reverse proxy

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: mm
      POSTGRES_PASSWORD: ${DB_PASS}
      POSTGRES_DB: mattermost
    volumes:
      - ./pgdata:/var/lib/postgresql/data

That file, a ${DB_PASS} in an .env, and a reverse proxy terminating TLS in front of it is a working chat server for twenty users or two hundred — the seat count changes nothing in the file. The point is not this particular tool; it is that the “self-hosted equivalent” in the table above is rarely more exotic than the block you just read. The bill it replaces scaled with your headcount. This does not.

The same shape applies right across the common per-seat offenders. A self-hosted password manager runs a whole family or team off one small container with no per-user fee, and moving your repositories off a paid Git host onto your own Gitea instance removes another linear bill entirely. In each case the interesting cost stops being the invoice and becomes the operational responsibility — which is precisely where the counterweight lives.

Where the self-hosted version bites back

Before you gleefully cancel everything, know the ways the escape route fails, because they are predictable and they are what the SaaS bill was quietly covering:

• Someone has to be on call. The vendor’s uptime included a team you never saw. Self-hosted, that team is you, at whatever hour the container falls over.
• Upgrades are now your problem. A breaking change in a major version, a database migration that needs a manual step, a deprecated config key — these arrive on the vendor’s schedule and land on your desk.
• Backups and restores are non-negotiable. A SaaS tool losing your data is their liability. Your box losing it is yours, and an untested backup is not a backup.
• Auth and access need real thought. SSO, sensible password policy, and locking the admin interface away from the open internet are all things the vendor handled by default and you now own.

None of these are dealbreakers, but they are real work, and pretending otherwise is how a “cost saving” turns into a burnt-out admin and a service nobody trusts.

When the trap isn’t actually a trap

Now the counterweight, because self-hosting to dodge per-seat fees can absolutely backfire:

• If the tool is mission-critical and downtime costs real money, paying the per-seat premium for someone else’s on-call rota is rational. Your time isn’t free either.
• If you have no one who wants to be the admin, the “saving” is illusory — you’ve just moved the cost from a budget line to a person who’ll burn out.
• If the seat count is small and stable, the crossover never arrives. Don’t self-host fifteen pounds a month of convenience.
• If compliance or data residency is handled for you, that’s a service with real value, not just a markup.

The honest framing is that per-seat pricing isn’t evil — it’s just misaligned past a certain size. Self-hosting realigns the cost with reality, but it hands you the bill in time and responsibility instead of money.

A middle path deserves mention, because the choice is rarely as binary as “pay per seat forever” or “run everything yourself”. Plenty of vendors offer a flat-rate self-hosted licence, a site licence, or an open-core edition that removes the per-seat mechanic while keeping you on supported software. If your objection is specifically the linear scaling rather than the hosting itself, that flat licence can be the sweet spot: you keep the vendor’s updates and support and lose the seat tax. It is worth asking for explicitly, because it is frequently available and rarely advertised — the per-seat plan is simply the more profitable default, so it is the one on the front page. Sometimes the escape from the trap is not self-hosting at all; it is a different line on the same vendor’s price list.

The honest verdict

Per-seat pricing is a fair deal for a small team and a worsening one for a growing one, because it charges you linearly for a service that mostly costs the vendor a fixed amount. The trap is real, but the escape isn’t free.

My rule of thumb: under ten seats, pay the SaaS and get on with your life. Between ten and thirty, run the numbers above with your actual rates and your actual appetite for admin. Above thirty, if there’s a mature self-hosted alternative and anyone on the team genuinely wants to own it, the savings are usually large enough to take seriously. Just go in knowing you’re trading a predictable invoice for an unpredictable evening — and make sure someone has actually signed up to be the person who fixes it.