Build or Buy: The Question Is What You Want to Keep Changing
The build-or-buy decision is usually settled on cost and time to value. Neither is the variable that matters. The useful question is which parts of the organisation you expect to keep changing — and who you are willing to ask first.
Every few years an organisation reaches the same fork. The current system will not do what is now needed — and somebody has to decide whether to buy a replacement or build something.
The decision is usually settled on cost and time to value. Neither is the variable that matters most.
1. The Comparison Everyone Runs
The business case compares licence and implementation fees against day rates and elapsed time. It runs over five years, it is careful, and it almost always favours buying.
That is not a fiddle. Buying genuinely is cheaper and faster for most things, and a vendor has already solved problems you have not thought of yet.
The trouble is what the comparison quietly leaves out.
2. What the Case Leaves Out
The licence is the visible number and rarely the largest one. Around it sit configuration, integration with everything you already run, data migration and testing. And the work of getting everyone who uses it to do their jobs differently.
Then there is the second implementation nobody plans for. The vendor’s roadmap moves and a major version arrives. The customisations written to make the product fit are then the reason the upgrade takes eighteen months.
The change cost is the one left out most often, and it does not scale with the size of the licence. It scales with how many people have to work differently, which is usually a much larger number.
None of that argues against buying. It argues against believing the five-year number.
3. Buying Is Not the End of Building
Watch what happens after a platform is selected. The organisation configures it to resemble the way it worked before — screens, workflows, rules, exceptions, reports.
That is building — in someone else’s product, in a language fewer people know, and without source control in any meaningful sense.
Most organisations that decide to buy end up building anyway, and own the cost of it without owning the thing.
4. The Real Test Is How Often It Has to Change
A better question than cost is how often the capability will need to change once it is live.
Payroll, general ledger, service desk — the rules are set elsewhere, they change slowly, and the process is common to every organisation of your size. Buy those, adopt the standard — and resist the temptation to make them yours.
Where you expect to change something every quarter, and changing it is how you compete, ownership starts to matter more than the initial price. The answer is rarely uniform across an organisation, either. Different capabilities deserve different answers — and treating it as one decision is what produces a single platform doing eight jobs badly.
5. Most of What Feels Special Is Not
The honest part of this is uncomfortable, and it is where the conversation usually stalls.
Almost every organisation believes its processes are unusual. Most of that belief is sincere. It comes from people who have spent years absorbing the exceptions, and who know exactly why each one exists.
But the test is not whether a process is complicated. It is whether a customer, a regulator or a competitor would notice if it disappeared tomorrow.
6. What You Own When You Buy
You own the outcome, the data and the regulatory risk. You do not own the roadmap, the release schedule or the priority of your defect against everyone else’s.
That is a reasonable trade for a commodity. It is an expensive one for the capability your market judges you on — because your ability to respond is now somebody else’s planning cycle.
This is the same conversation in a hospital, a network operator and a district council. Only the capability in question changes, and with it the answer.
7. The Shape That Usually Works
Most organisations do not need a pure answer, and the useful design is boring:
- buy the common capabilities and take them as they come
- build thinly, and only where the difference earns it
- keep your data where you can reach it, in a form you can move
- integrate deliberately, so replacing one thing does not mean replacing four
That last point does more for future flexibility than any decision about a single product.
8. Ask the Question Differently
Rather than which option is cheaper, ask two things. What will you need to change in three years’ time — and who has to agree before you can change it?
If the honest answer is a vendor’s product council, decide now whether that is acceptable for this particular capability. Frequently it is.
Nobody has ever regretted buying a payroll system. The regret is almost always about the thing that made the organisation different, handed over quietly to somebody else’s release schedule.