The hidden costs of SaaS once your business is established

Quick answer: the licence is usually 25–40% of the real total cost of SaaS once a business has more than ten staff and three or more platforms wired together. The other 60–75% is integration, configuration drift, training, lock-in, and the seat tax at scale — none of which appear on the invoice.

Most SaaS pricing pages quote you a per-user-per-month figure. That number is rarely the full story. By the time a business hits twenty staff — and certainly by fifty — the real cost of an off-the-shelf platform is two to four times the licence line item.

That’s not an argument against SaaS. SaaS is the right answer most of the time, and we say so on the build-vs-buy page we wrote for clients evaluating their options. But running a growing business on the assumption that the licence is the cost is how budgets quietly bleed.

Here’s where the rest of the money actually goes.

1. The integration tax

The single biggest hidden cost is wiring SaaS tools together. The number that keeps surprising owners we work with is this: by the time a business is using ten SaaS tools, integrating them is usually larger than the combined licence cost.

A typical mid-size operation we see: CRM (HubSpot or Salesforce), accounting (Xero), email (a Microsoft 365 or Google Workspace tenant), helpdesk (Zendesk or Freshdesk), file storage, payroll, project management, marketing automation, customer messaging, and ecommerce. That’s ten platforms in their cheapest form before anyone has talked about API integrations between them.

Out of the box, none of those tools talk to each other in the way your business needs them to. Customer in HubSpot doesn’t auto-create in Xero. Order in Shopify doesn’t pre-fill the project board. Lead score doesn’t flag in the helpdesk. Each gap is closed by either:

• A native connector (limited, often missing the field you actually need)
• A no-code automation tool like Zapier or Make (works for low-volume, breaks at scale)
• A custom API integration (proper code, but properly built)

The first option is rarely sufficient. The second tends to break under load and at month-ends — the times you can least afford it. The third works, but is rarely what was budgeted for.

[INSERT: a real client situation — e.g. “We worked with a [industry] business running on 14 SaaS tools, paying about $X/month in licences but $Y in Zapier-and-duct-tape automations that broke twice a quarter.”]

2. The seat tax

The next surprise is what happens to per-seat pricing as headcount grows.

A platform at $80/user/month is $960 per user per year. At ten staff that’s $9,600. At fifty, $48,000. At two hundred, $192,000. Per platform. Per year. With three or four core platforms, you’re north of half a million dollars annually before anyone counts the integration layer. Productiv’s state-of-SaaS data consistently shows mid-size businesses underestimating their actual SaaS portfolio by 30–40%, and that’s before counting integration costs.

Two things that compound the bill:

• Tier creep. Most useful features are gated behind the next tier up. The starter tier’s “automation” doesn’t allow conditional logic; you need Pro. The Pro tier doesn’t allow custom fields beyond ten; you need Enterprise. By the time you have what you actually need, you’re on the most expensive tier across the board.
• Read-only seat fees. Some platforms charge for users who only need to look at data — finance, leadership, the auditor. We’ve seen $40–$80 per month for users whose entire interaction is opening a dashboard once a week.

This is the cost line where building custom eventually wins. A custom-built platform is a fixed asset whose cost doesn’t scale with headcount. There’s a crossover point — usually somewhere between fifty and two hundred staff, depending on the use case — where the per-seat cost of SaaS overtakes the all-in cost of owning the equivalent system.

That doesn’t mean every business at fifty staff should rip out SaaS. It means every business at fifty staff should do the maths, and most never do.

3. Configuration drift

Every SaaS platform of any complexity becomes a small custom system over time. Custom fields, custom workflows, custom permission roles, custom reports, custom views.

Two things happen to that configuration:

• It evolves to match how your business works (good)
• It becomes undocumented institutional knowledge that lives in the head of one or two people (less good)

When those people leave, the system becomes a black box. The next operator inherits something that resembles the standard product but behaves differently in fifty subtle ways, and the cost of either learning it or rebuilding it is real.

The same platform, in two different businesses, isn’t really the same platform. We’ve audited HubSpot accounts where the standard CRM had been customised so heavily that what the team called “HubSpot” was effectively a bespoke system running inside a HubSpot wrapper — with all the SaaS pricing and none of the ownership.

4. The lock-in cost no one quotes

Migration cost only shows up when you try to leave. By that point it’s an audit of:

• All the workflows configured inside the platform (these don’t export)
• All the integrations connecting it to other platforms (these have to be rebuilt)
• All the historical data (often exports as CSVs that are missing referential integrity)
• All the embedded business logic in “automation rules” that aren’t portable to anything else
• All the staff training to a new platform’s UX

The result is that switching cost climbs every year you’re on a platform, regardless of price increases or feature changes. By year four or five, the cost of leaving is almost always higher than the cost of staying, even if the platform has objectively gotten worse for your use case.

This is the real meaning of the phrase “vendor lock-in.” It’s not malicious. It’s structural.

5. The training and onboarding cost

Every SaaS platform has a learning curve. Multiplied across staff, multiplied across platforms, multiplied across new hires every year, it’s a real annual cost that doesn’t appear anywhere on a SaaS invoice.

A reasonable estimate: 2–5 hours of staff time to onboard a new starter onto a single platform. With ten platforms and ten new hires a year, that’s 200–500 hours of productivity cost — about a quarter of an FTE — just to get people functional in the tooling stack.

Custom systems have onboarding costs too. The difference is that custom systems can be designed around how your business actually trains people. SaaS tools train your people in their patterns, not yours.

6. The cost of the missing feature

Every SaaS platform has the feature you wanted but couldn’t get.

[INSERT: a specific example — e.g. “a [client] asked their CRM vendor for a multi-currency reporting view. Quoted timeline: ‘on the roadmap.’ Two years later, still on the roadmap. Cost of the workaround: $X/month in a third-party reporting tool plus 8 hours/week of manual reconciliation.”]

Owning the system means features ship when you need them, not when the vendor’s product team has prioritised your problem against four hundred other customers.

What this doesn’t mean

It doesn’t mean SaaS is the wrong answer. For most businesses, most of the time, it’s genuinely the right call — and we’ll tell you that honestly when it is.

What it does mean is that the comparison “build a custom system for $X” vs “pay for SaaS at $Y/month” almost always undercounts the SaaS side. A fairer comparison includes:

• Per-seat licences across all tools
• The integration layer that wires them together
• The staff time spent maintaining the integration layer
• The cost of features you wanted but didn’t get
• The deferred migration cost when you eventually outgrow it

Run that comparison properly and a lot of decisions look different.

When the maths flips

A few signals that suggest the SaaS model is starting to cost more than it’s worth:

• Three or more platforms each costing over $50/user/month with significant overlap in functionality
• An integration layer (Zapier / Make / a part-time integrations contractor) costing more than one of the underlying platforms
• A specific business process that sits across four or more SaaS tools because no single tool covers it
• A feature you’ve been waiting on for over twelve months that the vendor “may” ship
• More than 20% of staff time spent in a tool whose UX doesn’t match how your team actually works

When two or three of these are true, it’s worth doing the proper maths. Not as a trigger to build custom — as a trigger to ask the question.

If you’re at that point, start a project and we’ll do the comparison with you. We turn down work where SaaS is genuinely the better answer; that’s usually the most useful conversation we have with a prospective client in any given quarter.

Common questions

Is SaaS cheaper than custom software? For most businesses under fifty staff, yes — substantially. Above that, the per-seat tax compounds, and the comparison flips for any platform that’s become business-critical and heavily customised. The honest comparison includes integration, training, and migration cost, not just licences.

What does “SaaS lock-in” actually mean? It’s the structural cost of leaving: workflows that don’t export, integrations that have to be rebuilt, historical data that exports without referential integrity, and staff retraining. Lock-in cost rises every year on a platform regardless of price.

When should we move off SaaS to custom software? A reasonable trigger: when three or more SaaS tools each cost over $50/user/month with overlapping functionality, when your integration layer costs more than one of the underlying platforms, or when you’re waiting twelve-plus months on a feature the vendor “may” ship. At that point, run the build-vs-buy framework properly.

How do I calculate the true cost of our SaaS stack? Add: licences across all tools, integration platform costs (Zapier/Make/iPaaS), engineering time on integration maintenance, the cost of features you wanted but didn’t get, and a discounted estimate of switching cost when you eventually leave. That’s the comparable figure to a custom build.

Do we have to rip out all our SaaS to build custom? No. Most realistic transitions replace one or two SaaS tools at a time, starting with the platform whose per-seat cost has gotten silly or whose missing features hurt the most. Custom and SaaS coexist well when the boundaries are drawn deliberately. We do this work as custom web apps projects.