Build vs buy: when does custom software actually earn its keep?

For most software a company needs, the right answer is to buy it. Accounting, email, CRM, helpdesk, payroll — these are solved problems, and a SaaS vendor amortises the cost of solving them across thousands of customers. Building your own is almost always a way to spend more money to get less software, later.

So the interesting question is not “should we build?” It is narrower: where does buying quietly stop working, and what does it cost when it does?

Buy is the default. Here is where it cracks.

Off-the-shelf software is a bet that your problem is the same as everyone else’s. For commodity functions, that bet is correct and you should take it every time. It breaks in three places:

• The tool fits 80% and the last 20% is your actual business. You end up bending your organisation to the software’s assumptions, or maintaining a fragile lattice of exports, scripts, and manual steps around it. The licence is cheap; the workarounds are not.
• The thing you’d be buying is your differentiator. If the software is how you compete — the operations platform your margins depend on, the product your customers actually pay for — renting a generic version of it caps your ceiling at whatever the vendor decides to build next.
• Integration and lock-in cost more than the licence. Per-seat pricing that scales faster than value, data you can’t get out cleanly, a roadmap you don’t control. The sticker price is rarely the real price.

Four questions that decide it

Before committing either way, answer these honestly:

1. Is this a differentiator or a commodity? If a competitor using the same off-the-shelf tool would be at no disadvantage, it’s a commodity — buy it. If owning it is part of how you win, that’s a candidate to build.
2. Does a real tool fit your real workflow — not a demo workflow? Pilot it against your messiest actual process, not the happy path. If you’re already planning workarounds during the trial, that’s the answer.
3. What is the total cost of ownership over three years, not three months? For buy: licences as you scale, integration, the workarounds, the switching cost when you outgrow it. For build: the initial engineering plus operating, security, and evolution after launch — the part most build estimates quietly omit.
4. Who operates it at 2 a.m.? Buying outsources the operational burden to the vendor; that has real value. Building means you own reliability, security, and incident response — which is fine if you plan for it, and ruinous if you treat launch as the finish line.

Build the part that is genuinely yours. Buy everything around it. Most failures come from getting this line wrong in either direction — building a commodity, or renting a differentiator.

What “build was right” actually looks like

The Ministry of Industry needed a national learning platform for Indonesia’s small and medium enterprises — under government-grade identity, security, audit, and procurement constraints, serving a highly variable national audience. On paper, “just use an off-the-shelf LMS” is the cheaper instinct.

It wasn’t, here. No generic LMS would sit inside the ministry’s identity surface, meet its audit posture from day one, or model the IKM industrial pathways the programme was actually about. Buying would have meant bending a national programme to a vendor’s assumptions, then maintaining the gap forever. Building — federated identity through Keycloak, curriculum modelled on real pathways, role-aware reporting, a hardened government-grade pipeline — was the cheaper decision over the life of the system, not the more exciting one.

That is the test. Not “would building be more capable?” — building is almost always more capable. The test is “is building cheaper over the life of the system, once you count operating it?” When the answer is genuinely yes, it is usually because the software is either your differentiator or a poor fit for anything generic. When the answer is no, buy, and spend the saved engineering on the part that is actually yours.

The senior move

Resist building the commodity, and resist renting the differentiator. Write the decision down with the three-year cost on both sides and the reason attached — so that in a year, when someone asks why this was built and that was bought, the answer is a document, not a memory.