The SaaS unit-economics trap: why per-user pricing punishes growth
Per-seat SaaS pricing isn't a number on a contract — it's a contract you sign with the vendor's incentive structure. Here's the math, and what to do about it.
A small business owner once told us: “Our software costs went from $4,000 a month to $11,000 a month, and nothing about the software changed. We just hired more people.”
That’s not a bug. It’s the SaaS pricing model working as intended.
This piece is for the operator who’s done that math, knows something is off, and wants to see the calculus underneath it.
The contract behind the price
When you sign up for a SaaS product at “$50 per user per month,” you’re not signing up for software. You’re signing up for an arrangement where:
- Your bill is a function of your headcount.
- The vendor’s revenue grows linearly with your team.
- Your switching cost grows with the depth of your data and the breadth of your integrations.
- Their incentive is to make (3) outpace your tolerance for (1) and (2).
That’s the unit-economics. It’s not personal. It’s not predatory. It’s the mathematical shape of a per-seat pricing model played forward over five years.
What the numbers actually look like
Imagine a small services business growing from 5 employees to 50 over 4 years. Run a typical mid-market SaaS stack against them — CRM, project tracker, accounting, communications, email marketing — and add up the per-seat fees:
| Stack tier | At 5 users | At 20 users | At 50 users |
|---|---|---|---|
| CRM ($25/seat/mo) | $125 | $500 | $1,250 |
| Project tool ($15/seat/mo) | $75 | $300 | $750 |
| Accounting ($10/seat/mo) | $50 | $200 | $500 |
| Comms/chat ($8/seat/mo) | $40 | $160 | $400 |
| Email marketing ($60/contact-tier) | $60 | $200 | $400 |
| Monthly total | $350 | $1,360 | $3,300 |
| Annualized | $4,200 | $16,320 | $39,600 |
Same five tools. Same business. Tenfold cost increase as the team grew tenfold.
Now run the same stack on owned infrastructure — open-source CRM, project tool, accounting, chat, email automation — on a managed European bare-metal cluster:
| Cost line | At 5 users | At 20 users | At 50 users |
|---|---|---|---|
| Hosting (managed cluster) | $50 | $50 | $100 |
| Database resources | $25 | $40 | $80 |
| Backups + monitoring | $20 | $20 | $30 |
| Per-user licenses | $0 | $0 | $0 |
| Monthly total | $95 | $110 | $210 |
| Annualized | $1,140 | $1,320 | $2,520 |
The total cost grows with workload, not with headcount. The 50-user business pays roughly 6% of what the SaaS stack would charge for the same functional outcome.
(Numbers above are illustrative — exact figures depend on your specific tools, scale, and configuration. The shape of the curve is what’s universal.)
Why the SaaS shape is engineered to punish growth
Per-seat pricing isn’t an accident of history. It’s a deliberate revenue-engineering choice:
- Predictable revenue per customer. Your headcount is a fact about your business. The vendor doesn’t have to guess at usage.
- Locked-in growth path. As your team grows, your bill grows automatically — without any sales effort on the vendor’s part.
- Asymmetric switching cost. The data, the workflows, the integrations, the team’s habits — all live inside the platform. The longer you stay, the harder it is to leave.
- Discount the entry, charge the back end. Cheap to start, expensive once you’ve grown into it. The pricing curve sits where you can’t easily see it from the trial.
None of this is conspiracy. It’s just what good revenue engineering produces when the constraint is “maximize lifetime value per customer.” The customer is on the wrong side of that constraint by definition.
The “but we use it for productivity” defense
A common pushback: “Sure, but the software actually works. We’re more productive with it. That’s why we pay.”
That’s true, and beside the point. The question isn’t whether the software is useful. The question is whether the delivery mechanism for that usefulness is the only one available.
For 95% of common business-software needs, an open-source equivalent now exists that:
- Provides the same core functionality
- Runs on infrastructure the customer owns
- Is professionally implementable in days or weeks
- Has no per-seat pricing — you pay for compute, not headcount
The friction isn’t features. It’s migration cost, operational unfamiliarity, and the (often outdated) belief that “open-source” means “I have to maintain it myself.”
What changes when the bill stops scaling with your team
The most underrated effect of switching to owned infrastructure isn’t the cost saving. It’s the change in incentives.
When your software bill is fixed, hiring becomes a pure productivity question. Should we add this person? Will they generate value above their fully-loaded cost? You don’t have to mentally subtract a “$600/month software tax” from each new hire’s contribution.
When your stack runs on infrastructure you own, your data is yours. Exporting becomes “run a backup script.” Migrating to a different open-source tool becomes a configuration project, not an existential one.
When the vendor’s incentive is to extract more revenue per customer over time, you have to manage the relationship as adversarial. When the “vendor” is your own infrastructure plus a team that implements and supports it for a fixed fee, the dynamic is different — closer to working with your accountant than negotiating with your phone company.
What we recommend
If you’re a small or mid-market business currently paying per-seat for the standard SaaS stack, three steps:
- Run the math. Total your per-seat-pricing line items annually, then project them forward at your expected headcount over the next 24 months. The number is usually larger than people expect.
- Audit what’s actually integrated. Most companies use 30% of the features they’re paying for in any given tool. The “platform” is often a small surface plus a lot of unused weight.
- Plan a migration in stages. You don’t have to leave everything at once. Pick the most expensive line first — usually CRM or marketing automation — and replace just that. Compound from there.
The math almost always favors ownership for businesses past about 10–15 employees. The reason most companies don’t switch isn’t the math — it’s the friction. We exist because that friction is solvable.