When to build your own internal software instead of buying SaaS

We make our living building custom software, so this advice runs against our own interest: most businesses should buy SaaS rather than build.

SaaS is two orders of magnitude cheaper, works immediately, and has been debugged by thousands of other customers. Custom software is only worth it for a specific reason. This article is about those reasons.

Three cases where building is right

1. Your process is the competitive advantage

If the way you work is why customers pick you over a competitor, forcing that process into a generic SaaS gives the advantage away.

A real case: a furniture workshop quotes using their own measuring method and returns a price in 24 hours while competitors take a week. No SaaS models that calculation. Their own software preserves the 24-hour advantage.

The test: if you explain your process to a SaaS vendor and the answer is "we do not support that, you would do it this way instead" — and that other way makes you slower than your competitor — you are in this case.

2. You are paying per seat for hundreds of people

SaaS charges per user per month. At eight people that is cheap. At two hundred it becomes a permanent line item.

Concretely: 200 users × $12 a month = $2,400 a month, around 62 million VND. That is 750 million a year. Custom software covering just the part you need might cost 300–500 million once, plus modest running costs.

Break-even usually lands at 18–30 months above about a hundred users. Under thirty users, it essentially never breaks even.

3. The data cannot leave your systems

Medical records, biometric data, contracts with confidentiality terms requiring in-country storage. This is a legal reason rather than a technical one, and it is not negotiable.

Four cases where building is wrong, however reasonable it sounds

"That SaaS is missing three features I need." Three features do not justify custom software. Count the hours those three features cost you each week, multiply by your hourly cost, and compare against a few hundred million VND. Usually it does not add up — and usually those three features arrive in next year's release.

"With custom software I own it and pay nothing monthly." You still pay monthly — hosting, maintenance, somebody to fix it when it breaks. Custom software has no subscription, but it has a cost of ownership, typically 15–20% of the build price per year.

"My data is unusual." Almost always untrue. Orders, customers, products, stock — these are the same in 95% of businesses. The feeling of being unusual usually comes from internal terminology, not data structure.

"I want software exactly the way I want it." The most expensive emotional reason. Software exactly as you want it today will not be what you want in a year, and then you are the only one paying to change it.

The third path: buy SaaS, build the joint

The right answer for most clients we meet, and rarely offered because it is the smaller contract.

Keep SaaS for the generic parts — accounting, attendance, CRM. Then build one thing: the process that is genuinely yours, connected to the SaaS through its API.

For example: keep the accounting package, build your own quoting tool using your measuring method, and have it push invoices into the accounting system. That costs a fifth of a whole-system build, and you keep the competitive advantage.

One condition: the SaaS must have an API. Check before you plan, because many local packages do not.

The four-question test

Answer these before calling anybody:

1. Is this process why customers choose you? No → buy SaaS.
2. Are there more than a hundred users? No → buy SaaS, unless (1) was yes.
3. Is there a legal constraint on where data lives? Yes → build; there is no choice.
4. Does your current SaaS have an API? Yes → consider the third path before a whole-system build.

If you decide to build

Start with one workflow, not the whole company. Read the MVP article for how to phase it, and the pricing article to estimate cost before asking.

And when you do ask us, expect a question back: which SaaS have you tried, and what exactly was missing? If you have not tried one, we will suggest you try first. Three weeks trialling a SaaS is cheaper than three months of development spent discovering that the SaaS was enough.