The build or buy conversation is usually a licence fee against a day rate. That comparison is the wrong one, and it is why organisations end up maintaining software they never meant to own, or paying a subscription for something that does eighty per cent of what they need.
The comparison people make
Buy: £9,000 a year. Build: twenty days at £600, so £12,000, then it is ours.
By that arithmetic, building wins in the second year. It almost never does, because the £12,000 is the cost of the first version and nothing else.
What building actually commits you to
- The first version, which is the part everybody estimates.
- The second version, because the first is always wrong somewhere, and that is not a failure, it is what building is.
- Keeping it running. Somebody patches it, renews the certificate, and fixes it when a dependency changes under it.
- Knowing how it works. One person understands it. That person leaves. The next one spends a fortnight reading, or rewrites it.
- Being the support desk. When it breaks, nobody can be rung.
None of that is an argument against building. It is the real cost, and it wants to be in the comparison rather than discovered in year two.
What buying actually commits you to
- The subscription, forever, usually rising.
- Their roadmap. What you need next may never arrive.
- Their shape. You will change how you work to fit the product, often in ways nobody decided to.
- Getting your data out, which is easy to check before signing and impossible to fix afterwards.
- Their existence. Small vendors are acquired and shut down.
The question that actually decides it
Is this thing how you are different, or is it plumbing?
If the process is one of the reasons customers choose you, the shape of it matters and bending it to fit somebody else's product costs more than the licence ever will. Build it, own it, and accept the maintenance.
If it is plumbing, expense claims, holiday booking, a ticket system, buy it. Nobody chose you because of your expense process, and every hour spent on it is an hour not spent on whatever they did choose you for.
Most arguments about build or buy are really disagreements about which of those two a thing is, and having that argument openly is quicker than having it through cost estimates.
Three questions that usually settle it
How much of what you need does the product do today? Not on the roadmap. Today. Under about seventy per cent, you will be building anyway, around the edges, in the worst possible place.
What happens when the person who built it leaves? If the answer is a shrug, the real cost of building is higher than the estimate.
Can you get your data out, in a form something else can read? Ask for an export before signing, not a promise of one. This is the question that decides whether buying is a decision or a marriage.
The answer nobody offers
There is usually a third option: buy the plumbing and build the small part that is actually yours. A bought system for the general job, and a hundred lines that do the bit nobody else does, connected by an API.
It is less satisfying than either pure answer and it is very often right.
If you are weighing this up and want somebody to say plainly which of the two it is, that is a conversation worth having before either bill starts. We say when something is not worth building, including when that means less work for us.
This is part of what we do under Software development. See the services, or tell us what is not working.