Build versus buy, decided by the change rate

The build-versus-buy conversation usually starts with licence cost. That is a real input, and it is also the one that moves least over a system's life.

The input that actually determines the cost is how often your process will differ from everyone else's, and how expensive that difference is to express.

Reframe it around the change rate

Two systems can both be functionally sufficient today. They differ in what happens the first time you need something unusual.

A configurability test helps: how many of your required behaviours can the vendor express without writing code? Count them honestly. Then count how many require customisation, a data extension, or a support ticket.

If the answer is "one, and it is important", buy. If it is "four, and they interact", the product is going to be extended permanently, and you are maintaining a fork with a support contract attached.

Buy when the process is standard

Off-the-shelf wins when your process is genuinely standard and the data is load-bearing. Payroll, standard expense, common CRM patterns.

You get fixes you would not have found, security patches, and integration ecosystems. The risk is the vendor's roadmap, which you do not control.

Build when the process is the advantage

Build when the process itself is a source of commercial value — a pricing rule, a credit model, a claims decision, a production schedule. In these cases the process changes often, changes for competitive reasons, and differentiating from a competitor depends on changing it quickly.

The cost of buying here is that every meaningful change routes through someone else's roadmap.

The middle, which is most of the estate

Most enterprise systems are neither. They are a bought core with configuration and a significant layer of customisation on top.

That middle has its own failure mode: teams underestimate the customisation layer and discover it is doing the work the product was bought for.

The way to handle it is explicit. Write down what the product does unmodified. Everything above that line is yours, and it needs the same testing, documentation and ownership discipline as code you wrote.

Migration cost is routinely underestimated

The cost of changing a system later is not the licence difference. It is:

• Data migration, including the cleanup nobody budgeted for
• Re-learning the domain, which for a specialist platform is months
• Losing institutional workarounds that were never documented and are load-bearing
• Dual running, almost always longer than planned

For a core banking or claims platform, switching after seven years costs more than the original implementation. This argues strongly for build or extend, and against casual replacement.

Total cost needs a horizon

Three years of subscription looks cheaper than three years of internal development. The comparison usually inverts over ten, and systems in this category live for ten to twenty.

Set the horizon honestly. For a claims platform or a core banking interface, ten years is realistic. For a marketing site, three.

The decision criteria worth writing down

Before deciding, get explicit answers on:

• how often will we need to change this, and who decides
• how many required behaviours need code rather than configuration
• what is the cost and duration of leaving in year five
• where does the data live, and what happens to it if we leave
• who owns it after go-live, and are they paid for that

The fifth is the one most often skipped, and the one most correlated with whether the system still works in year four.

A practical rule

Buy what is genuinely standard and commodity. Extend what is standard with a well-understood customisation layer you own. Build only where the process is the competitive advantage — and be honest with yourself about which category each system is in, because the answer is usually not the same for all of them.