Build or buy is the wrong question

Somebody eventually asks whether we should build this or buy it. The discussion that follows is usually about cost and control, and it usually ends in a decision applied to the whole system.

That is the error. It is not one decision.

The question behind the question

Any system of consequence has parts that differ in two ways that matter: how quickly the requirement changes, and where your differentiator resides.

Payroll calculation rules change when legislation changes and contain none of your competitive difference. The way you price a risk, or sequence a field crew, or decide which claim needs a human, might be most of it.

Once you separate the parts on those two axes the decision mostly makes itself. Common and slow-moving is a purchase. Specific and fast-moving is something you want to be able to change on a Tuesday without raising a support ticket with a vendor in another time zone.

The expensive mistake is the inverse: an organisation builds and maintains its own version of something entirely standard, while the part that carries its actual advantage sits inside a package it cannot alter.

Why AI assistance did not settle it

There was a view last year that cheaper software production would tilt everything towards building. It has not, and the reason is the same one as in the previous piece in this series.

Production was never the whole cost. The cost is what you take on: the decisions, the upgrades, the obligation to keep something correct for as long as it is in use, the person who has to understand it in four years when nobody who wrote it is still here. None of that got cheaper. Some of it got slightly harder, because work that is quick to produce is also quick to accumulate.

Cheaper production does change one thing. It lowers the threshold at which building the specific part becomes reasonable. Work that was not worth custom software at last year's cost sometimes is at this year's.

A way to run the decision

We use four questions, in order.

Does this requirement differ from how others in the sector do it, and does the difference matter to a customer? If not, you are describing a purchase.

How often does it change? Something that changes monthly and sits behind a vendor release cycle will be a source of friction for as long as you own it.

What is the cost of being wrong for six months? This is the one people skip. It separates decisions that deserve an evaluation from decisions that deserve an afternoon.

What does the exit look like? A system you cannot leave will eventually be priced accordingly.

Integration is where it is actually decided

Most of this is settled by integration.

A purchased system that exchanges data cleanly with the rest of the estate is an asset. The same system, reachable only through a nightly file and a manual reconciliation, is a problem that grows. We have spent years working on that seam, and the pattern repeats: the organisations that move quickly are the ones whose systems can talk to each other without a project.

Most of our integration work since the BizTalk years has been on that seam, and it is where we start with a new client estate: a map of what was bought, what was built and how each part is reached, before anyone proposes replacing anything. The patterns we use are set out under API management and events, messaging and data, and the route off an ageing platform under legacy modernisation.

So: which parts of this do you intend to still control in five years, and can the things you did not build be reached by the things you did?

From what gets built to how it gets delivered: the next piece is about what changes, and what must not, when a tool is drafting the work.