Build vs buy: when does it make sense to build your own system?

The question everyone asks, nobody answers well

At some point in an organisation's maturity the question arrives: should we build our own system for this, or buy a SaaS solution?

The standard answer is "buy, don't build". It is often right. The standard answer is also wrong in almost all the interesting cases, because the interesting cases are precisely those where the choice is not obvious.

We have sat on both sides of this question many times. As a supplier we have built custom systems where clients might have chosen SaaS, and we have seen SaaS solutions that have kept clients locked in for years with growing frustration because the alternative, building themselves, seemed overwhelming. Here is the framework we use when someone asks us whether to build or buy.

The four scenarios

There are four typical build-or-buy situations:

1. Clear buy: generic process, many users

If the process is the same as thousands of other companies need (accounting, payroll, CRM for ordinary B2B sales, e-mail marketing), and you have many users who will use it, buy. SaaS vendors have invested more in UX, security, and compatibility than you can build.

Example: if a company with 50 employees needs accounting software, the answer is an established accounting SaaS, not something custom.

2. Clear build: unique process, critical to the business

If the process is the core of what you do, and no standard solution matches because you have a unique approach, build. This is rarer than people think, but when it is the case, it is obvious.

Example: a healthcare organisation that wants to offer patients a completely new type of follow-up journey that does not exist in standard patient portals. This is the core service, and it must fit their model.

3. Difficult: hybrid or integration

Many companies are in the middle ground: the process is not unique enough to justify full custom work, but not generic enough for a SaaS to cover it completely. The answer is usually "buy plus build": buy the base platform, build the integration layer and the unique parts on top.

Example: a logistics firm using standard ERP, but building their own route-optimisation tool that pulls data from the ERP.

4. Complex: legacy SaaS that no longer fits

You have a SaaS that has grown with you for five years, but now constrains you. You are considering building your own. This is the most difficult situation, because the inertia cost of switching is high, while the cost of continuing without switching is also high.

Our experience: if the SaaS costs more than you would spend on your own development in a typical month, and you have been complaining about its limitations for a long time, it is time to consider building your own.

The eight questions that decide it

Instead of guessing, go through these questions with your development partner:

1. How many users will the system serve?

Fewer than 5: SaaS is almost always right. More than 50: custom should be considered seriously. In between: depends on factors 2 to 8.

2. How much of the process will you change from "standard"?

If the answer is "10 to 20%", buy standard with adaptations. If the answer is "over 50%", build your own.

3. How many integrations with existing systems are needed?

More than three complex integrations argue for building your own, because SaaS makes integrations expensive and rigid.

4. What is the cost envelope over three years?

Calculate: SaaS licence x users x 36 months + integration work + adaptation costs. Compare with initial build cost + three years of operation and further development. Building your own often wins over a three-year horizon when the SaaS monthly bill gets high enough and the adaptations are numerous enough.

5. How unique are the data and the reports?

If you need reports that SaaS cannot generate, and data you cannot export from the SaaS, build your own.

6. What happens if the SaaS vendor changes pricing or functionality?

If the answer is "we have no choice", you are already locked in. Building your own gives you control over the course.

7. What is your core competence?

If the process is the core of what you compete on, build your own. If it is a support process you simply need to have, buy standard if possible.

8. How much do you own of the data?

SaaS vendors own the data format. That means you are locked into their upgrades, their error messages, their pricing model. Building your own gives full control.

What the calculation looks like

Imagine a business with many case handlers using an international SaaS for case management, with a per-user monthly licence. Over a three-year horizon the licence cost becomes significant. Add adaptations maintained externally, and integrations against the ERP that are rigid and break at upgrades.

A pre-project clarifies what a custom alternative actually costs to build and operate. In many such cases we see that an own system can cover the vast majority of the need, at a total cost over three years that is lower than continuing with SaaS plus adaptations.

The calculation is set up like this:

• SaaS: licence x users x 36 months + adaptation and integration maintenance
• Build your own: initial build cost + operation and further development over 3 years

For organisations with many users and heavy adaptations the difference can be large. The point is not a definitive answer, but that the calculation must be set up concretely for your situation.

This example is not universal. For smaller organisations the calculation is often reversed. For more complex ones the gain may be greater.

What people consistently underestimate

Three costs we consistently see people underestimate:

1. The adaptation cost of SaaS. Most larger SaaS solutions require 6 to 18 months of implementation, extensive consultant assistance, and specialist training of internal users. This often costs more than a pre-project and the first version of an own system.

2. The cost of shaping the business around a SaaS tool. Many companies change real workflows to fit what the SaaS supports, not the other way around. That is a hidden cost that does not appear on the SaaS invoice.

3. Loss of control over the direction. When the SaaS changes its pricing model, removes features, or is acquired and changes direction, you have no influence. For processes that are critical, that is an operational risk.

And two costs people often overestimate:

1. Initial build cost. Most assume building your own costs far more than it actually does. An MVP of a typical line-of-business system is often well below what people fear. It is still an investment, but rarely of the magnitude many envision.

2. Risk of it going wrong. A custom system built with a competent partner, fixed price after pre-project, sprint delivery every two weeks, carries relatively low risk. The risk comes from poor scope management, not from building.

Our recommendation

If you have more than 20 users on an internal process that matters to the business, do the review. In particular, set up a calculation over three years, accounting for both SaaS licence, adaptations, and the cost of shaping the process around the SaaS.

If the numbers point to building your own but you are nervous about the risk, start small. A pre-project costs 50 to 150k, and you own the result, even if you choose to continue with SaaS. It is the cheapest insurance against making the wrong decision.

We do these evaluations regularly, both for clients who end up building and for clients who end up staying with SaaS. We recommend what is right, not what gives us the most work. Send us a short note if you would like an outside view on the decision.

You can also read about what we offer in systems development, or our approach as a development partner.