Buy or build? A decision that costs more than people think

For twenty years the sensible advice to any smaller business was straightforward: buy. Building software was expensive, slow and risky, and there was a product on the market for almost everything.

That advice was correct. It is now only sometimes correct, and the reason is simply that building has become dramatically cheaper.

What has actually changed

A bespoke internal tool that would have cost eighty thousand pounds and taken nine months in 2018 might now cost fifteen thousand and take eight weeks. The economics have not shifted slightly. They have shifted by roughly an order of magnitude.

That does not mean build everything. It means the threshold moved, and a lot of decisions made under the old economics deserve revisiting.

Buy when the problem is genuinely standard

Payroll. Accounting. Email. Payments. Video calls.

These are solved problems where the existing products are excellent, cheap relative to their value, and maintained by teams larger than your entire business. Building your own payroll system is not brave, it is a mistake.

The test is whether your requirements are meaningfully different from everyone else's. For accounting, they are not. HMRC has opinions and the product already implements them.

Build when the process is the differentiator

If a process is the reason customers choose you, buying generic software for it means running the same process as your competitors.

We worked with a business whose scheduling approach was genuinely better than anyone else's in their sector. It was their entire competitive advantage, and it lived in a spreadsheet, because every scheduling product on the market forced a different model. Building was not an indulgence. It was protecting the thing that made them money.

The hidden costs of buying

Off-the-shelf rarely stays cheap.

There is the per-seat pricing that grows as you do. The integration work needed to make it talk to everything else. The consultant required to configure it. The process changes forced on you by the product's assumptions. And the gradual accumulation of workarounds for the things it nearly does.

Add those honestly to the licence fee and the comparison shifts.

The hidden costs of building

Equally, be honest about these.

You own it forever. Someone must maintain it, update dependencies, fix things when they break, and understand it when the original developer has moved on.

There is no community, no documentation written by strangers, no Stack Overflow answer for your specific problem.

And the first version will not be right, so budget for a second.

A practical test

Score the process out of five on four things: how standard it is, how central to your competitive position, how well the available products actually fit, and how often you would need it to change.

Standard, peripheral, well-served, stable: buy, without agonising.

Unusual, central, badly served, frequently changing: build, and stop feeling that you need permission.

Most things fall in between, and for those the useful question is whether a bought product plus some bespoke integration gets you most of the way. Frequently it does, and that hybrid is the answer people overlook because it does not fit neatly into either camp.