When to build software instead of buying it

The default should be buy, and usually is not the argument

Buying is correct most of the time and it is worth stating plainly. A mature product carries years of accumulated handling for cases you have not thought of yet, a support obligation that is not yours, a security posture maintained by someone else, and a roadmap funded by hundreds of customers rather than by your own budget. Matching that from scratch is expensive in a way that is easy to underestimate at the proposal stage and impossible to ignore three years in.

The build case therefore has to overcome a real advantage, not merely a preference. "The product does not do it the way we do it" is not a build case on its own — it is frequently an argument for changing how you do it, and the discipline of adopting a well-designed product's assumptions has made plenty of businesses better.

What follows is not a case against buying. It is a description of the specific circumstances where buying stops working, because those circumstances are real and recognising them late is expensive in the other direction.

The test that actually discriminates

The useful question is whether the process you are encoding is a reason customers choose you. Most business processes are not. Invoicing, payroll, expense approval, ticketing, basic CRM — these are undifferentiated. Doing them unusually is not an advantage, it is an overhead, and a product should be bought and adapted to.

A minority of processes are different. They are the thing the business is actually good at: the way a specialist logistics operator sequences a complex movement, the way a manufacturer configures a made-to-order product, the way a clinical group triages referrals, the pricing logic a distributor has refined over decades. These processes are why the business wins work, and forcing them into a generic product either degrades them or produces a configuration so elaborate that it has become custom software with none of the advantages of custom software.

So: does the process differentiate you, or does it merely differ? Differentiation justifies building. Differing usually justifies changing.

Undifferentiated process

Buy. Adopt the product's assumptions and spend the saved effort elsewhere.

Differing but not differentiating

Buy and change the process. This is the case most often misdiagnosed as a build case.

Genuinely differentiating

Consider building — but build only that part, and buy everything around it.

No product exists

Rare and real. Verify it properly before accepting it, because "we looked and there is nothing" is frequently "we searched for the wrong category".

Configuration cost is the signal to watch

There is a reliable warning sign that a product has stopped fitting: the configuration becomes an asset that needs its own expertise, its own documentation and its own change control. Custom fields nobody can remove because something depends on them. Automations layered on automations. A spreadsheet that reconciles the product's output because the product cannot produce what is needed. A consultant retained permanently to maintain the configuration.

At that point the organisation is already maintaining custom software. It is simply doing so in a form where it cannot test properly, cannot version control, cannot hire for the skills easily, and pays licence fees on top. This is the most common route into a justified build project, and it is usually recognised years after it should have been.

The honest test is to price the current arrangement fully: licences, the consultant, the internal time spent maintaining configuration, and the cost of the workarounds — the reconciliation spreadsheets and the re-keying. That total is the number a build has to beat, and it is frequently much larger than the licence line anyone quotes.

The costs that get left out of build estimates

Build estimates are almost always wrong in the same direction, and predictably so. The build itself is estimated reasonably; everything after it is not.

What gets omitted: the second year, when requirements have moved and nobody budgeted for change. Support, when something breaks at a time that matters. Security maintenance, which is continuous and not optional. Documentation, without which the system becomes dependent on whoever wrote it. The dependency upgrades that are boring and unavoidable. And the succession problem — what happens when the person who understands it leaves, which they will.

A defensible build case includes an annual running cost, not just a delivery cost. If that annual figure is not in the comparison, the comparison is not a comparison. Our own rule is that a build is only worth proposing when it still wins after three years of full running cost, because two-year paybacks in this category have a habit of not arriving.

Build the differentiator, buy the rest

The most durable pattern is rarely all-or-nothing. It is a bought core — accounting, CRM, HR, whatever is undifferentiated — with a built component handling the specific thing the business does well, connected properly.

This is harder to sell internally than either extreme, because it requires integration work that neither vendor is responsible for, and integration is where the unglamorous cost sits. It is nonetheless usually right: it confines the custom surface to where it earns its keep, and it leaves the maintenance burden of everything else with the people who sell it.

It also fails in a specific way worth naming. If the integration is built as a one-way overnight file, the two halves drift, and within a year someone is reconciling them manually. The integration deserves the same design attention as the application, including what happens when one side is unavailable and how conflicts resolve. Treating it as plumbing is how a good architecture becomes a bad one.

Exit is a design requirement, not a formality

Whichever way the decision goes, the thing to protect is the ability to change your mind. For bought software that means checking, before signing, whether your data can be extracted in a usable form — not whether an export exists, but whether the export contains the relationships and history rather than a flat list of current records.

For built software it means the same discipline applied to yourself. Standard formats, documented schemas, no dependency that cannot be replaced, and a written explanation of why the system works the way it does. Software you own can lock you in just as effectively as software you licence, and it does so quietly, because there is no renewal date to force the question.

We include exit provisions in what we build for the same reason we check them in what we recommend buying: a supplier who makes leaving difficult is telling you something about how they expect to retain you.

When building is straightforwardly wrong

There are cases where the answer is no regardless of the arithmetic. If the organisation has no capacity to own software — nobody who will be responsible for it, no budget line for its second year — then building creates an orphan, and an orphaned system is worse than a constraining product.

If the process is genuinely regulated in a way that products have already solved — payroll calculation, tax filing, certified point of sale in the markets that require it — building means taking on a compliance burden that a vendor currently carries for you, and the saving will never justify it.

And if the driver is dissatisfaction with an implementation rather than the product, building will reproduce it. A badly implemented CRM does not become a good custom platform; it becomes a badly implemented custom platform with a longer timeline. That diagnosis is worth making honestly before anything is scoped.

A sequence that keeps the decision reversible

The way to make this decision well is to make it late and cheaply. Start by writing down the process as it actually runs, including the exceptions, because the exceptions are usually what the product cannot handle and they are usually undocumented.

Then search the market properly — including the specialist products for your sector, which are frequently missed because the search started with the general category. If something fits at eighty per cent and the missing twenty per cent is not differentiating, buy it and change the twenty.

If nothing fits and the gap is differentiating, build the smallest thing that proves the process works, run it alongside the existing arrangement, and only then decide whether to extend it. A build that starts by replacing everything has committed before it has learned anything, and it is the version of this project that most often ends badly.

Where this sits in what we do

This article covers one decision inside a wider engagement. The solution page sets out how that engagement runs, what it includes and what it costs to find out.

• Custom Business Platform — A platform built around how your business actually runs — customer portal, internal tooling, database and the automation between them.
• AI for custom customer care: what it can answer and what it must not
• Why more traffic rarely fixes a pipeline problem
• Lead scoring that sales will actually use
• Quote to cash without re-keying: where the handoffs break
• All insight articles