Replacing SaaS With Something You Build: When the Maths Works

The argument is easy to make in a slide. The subscription costs a substantial amount per year, the tool does perhaps a fifth of what you need, and building the equivalent now looks far cheaper than it did three years ago.

Sometimes that is right. More often the comparison is between a real number and an incomplete one, and the incomplete number is yours.

What the build estimate usually leaves out

The first version is the cheapest part and the easiest to estimate, which is why it dominates the conversation. What follows does not appear:

• Integrations. The vendor maintains connectors to the systems you use, and they break when those systems change. That maintenance transfers to you entirely, and it is continuous rather than one-off.
• The compliance surface. If the tool touches regulated data, you inherit the controls, the audit evidence and the questionnaires your customers send. Vendors amortise that across their customer base; you will not.
• Availability expectations. Internal tools acquire the same uptime demands as the SaaS they replaced, and now the pager is yours.
• The long tail of features. The 80% you do not need contains a handful somebody depends on, discovered after cutover.
• Ownership after the builders move on. The three-year cost is dominated by whoever maintains it in year two, and that person is usually not the person who wrote it.

Where building genuinely wins

Two situations, reliably.

The workflow is your actual differentiator. If how you do this thing is why customers choose you, a generic tool forces you toward the industry-standard version of your own process. That is a strategic cost, not a licensing one, and it does not show up in a spreadsheet.

The integration burden already exceeds the tool. When a team spends more effort bending a product to fit than the product removes, the subscription has become the smaller half of the cost. This is common with tools bought for one use case and stretched across five.

A weaker but real third case: the vendor has become a concentration risk — pricing changes you cannot refuse, a roadmap diverging from your needs, or an acquisition. That justifies optionality, though usually the answer is an abstraction layer rather than a rebuild.

Where building reliably loses

Commodity functions with strong network effects or heavy compliance load. Payroll. Payment processing. Identity. Email delivery. These look tractable and are not: the difficulty is in the regulatory surface and the long tail of edge cases, not the happy path.

Anything where the vendor's value is data you do not have — benchmarks, fraud signals, deliverability reputation — cannot be rebuilt at any price, because you are not buying software.

The failure mode: rebuilding the SaaS

The version that goes worst is a faithful reimplementation of the product being replaced, feature for feature. That guarantees the worst outcome: you take on the full scope, without the vendor's accumulated edge-case knowledge, and you still cannot differentiate because you built a copy.

If building is right, build the thing your process actually needs. That is usually much smaller than the product, which is what makes the economics work. Scope discipline is the whole argument — without it the case collapses.

Design the exit either way

The strongest argument in this debate is rarely cost. It is control — the fear of being unable to leave.

That fear is addressable without a rebuild, and addressing it is cheaper than either option. Own your data in a form you can export and actually use, not a proprietary dump nobody has ever restored. Keep the integration behind an interface of your own, so replacing the vendor is a swap rather than an excavation. And test the export occasionally, because an export path nobody has exercised is a theory.

Teams that do this find the build-versus-buy conversation gets calmer, because the downside of staying has shrunk. Teams that do not are usually deciding under a pressure that has more to do with feeling trapped than with the economics.

The same discipline makes the build case honest. If you cannot describe how you would migrate off the thing you are about to build, you are proposing to replace one lock-in with another, and this one has your name on the pager.

How we would frame the decision

Compare over three years, not one, and include maintenance, on-call, compliance effort and the cost of the engineers not doing something else. Against that, count the subscription plus the current cost of working around its gaps.

Then apply a scope test: can you name the 20% of the tool you actually use, and is that 20% genuinely specific to you? Two yeses make a reasonable case. A no on either means you are about to rebuild a product.

Where it is genuinely close, the strongest move is often neither: keep the tool, put a thin interface in front of it, and build only the differentiated slice against your own data. You get the specificity where it matters and keep the vendor's maintenance everywhere else.

One caution on timing. This decision tends to surface at renewal, under a deadline, which is the worst moment to make it — the deadline favours whichever option needs no decision, and the analysis gets compressed into whatever fits before the invoice. Start the assessment two quarters out, when you can still choose to do nothing on purpose rather than by default.

We work through this in build versus buy, and deliver it through custom software development.