Build or buy: when custom software actually pays for itself

<strong>Is this process how you compete?</strong> If the way you do something is the reason customers choose you, it belongs in software you control. If it is a process every company in your industry performs identically, buy it. A logistics company's routing logic is a differentiator; its payroll is not.

<strong>Does a product fit without distorting how you work?</strong> Every off-the-shelf product encodes assumptions about process. If those assumptions match yours, you get enormous value cheaply. If they do not, you either change how you operate to suit the tool or you pay for customisation until you have built something bespoke on someone else's foundation, which is the worst of both.

<strong>What does it cost at the scale you are heading for?</strong> Per-seat pricing that is trivial at 20 users can be substantial at 500. Run the numbers at your projected size, not your current one.

If the answers are no, yes, and acceptable, buy it and move on. Genuine build cases are less common than engineering teams believe and more common than procurement teams believe.

The most frequent error in these decisions is comparing a build quote to an annual licence fee. They are not comparable, because the build quote covers construction and the licence covers construction plus operation plus improvement in perpetuity.

Custom software carries ongoing costs that are easy to omit: dependency and security updates, infrastructure, monitoring, bug fixing, and the feature work needed as the business changes. A reasonable planning figure is 15% to 25% of the original build cost per year, indefinitely.

It also carries a knowledge cost. Someone has to understand the system. If that is one contractor who moves on, you have an asset nobody can safely change — a common and expensive failure that has nothing to do with code quality.

None of this argues against building. It argues for building deliberately, with the running cost budgeted from the start rather than discovered in year two.

Buying has its own hidden line items. Implementation and data migration frequently cost more than the first year of licences. Integration with your other systems is rarely included. Training and change management are real.

Then there is the cost of the gap. Where the product does not quite fit, people build workarounds — spreadsheets alongside the system, manual reconciliation, exports and re-imports. That labour is a permanent tax that never appears on the invoice, and in our experience it is the most commonly underestimated cost in the entire comparison.

Finally, consider exit. How hard is it to get your data out in a usable form? A product that is cheap to enter and expensive to leave is a strategic risk regardless of price, particularly where it holds the record of something central to your operation.

Framing this as a binary produces bad decisions. The strong pattern is to buy the commodity layer and build the differentiated layer on top.

A field services business should not build accounting, payroll, or email. It might well build scheduling and dispatch, because that is where its margins are made. Those two decisions are entirely compatible, and the interesting engineering question is the integration between them.

This is where integration quality determines whether the strategy works. Buying five products that do not talk to each other creates the manual reconciliation tax described above. The build effort often belongs in the connective tissue — a layer that keeps systems in sync and gives you one coherent view — rather than in replacing any of them.

Judged this way, custom development is frequently smaller in scope than expected and more valuable, because it targets exactly the part nobody sells.

Many build-versus-buy questions are really replacement questions, which changes the analysis. The existing system holds years of data, encodes undocumented business rules, and is load-bearing.

Resist the full rewrite. Replacing a working system wholesale is the highest-risk option available, and the version of this story that ends badly usually involves a two-year project that never quite achieves parity.

The safer route is incremental: identify the most painful capability, build or buy a replacement for that one piece, run it alongside the old system, and migrate the next piece once it is stable. Slower on paper, far more likely to finish, and it delivers value from the first increment rather than at the end.

Above all, extract the business rules before you replace anything. The undocumented logic inside a legacy system is usually the most valuable thing about it, and the most common cause of replacement projects failing is discovering those rules only when something breaks in production.

For EU organisations, data residency and GDPR obligations often narrow the buy options more than functionality does. A product without an EU hosting region or a workable data processing agreement may be excluded before features are compared.

South African businesses face the same pattern under POPIA, with the added consideration that per-seat pricing denominated in dollars or euros carries currency risk that changes the total-cost comparison materially over a multi-year term.

Australian organisations frequently weigh support hours: a vendor whose support operates only in US business hours can turn a minor issue into a full-day outage. Where a system is operationally critical, that is a legitimate argument for owning it.

Across all four markets, the calculation shifts with headcount. Buying almost always wins at small scale, and the balance tips toward building as per-seat costs compound and the fit gap widens.