Build vs buy software in the UK: the arithmetic, not the principles

Decide by function, not by company

The most common mistake is treating build-versus-buy as a company-wide philosophy. It is not. It is a decision you take one function at a time, and a healthy business will land on different answers for different processes.

Payroll, accounting, email, calendars, basic CRM — these are commodity processes. Your competitors run them identically and no customer chooses you because of how you do payroll. Buy them, and do not customise them.

The processes worth building are the ones that are the reason customers choose you. The scheduling logic that makes your delivery faster. The pricing model nobody else uses. If you are bending your competitive advantage to fit somebody else's software, that bending is the cost, and it does not show up on any invoice.

The number that belongs opposite the build price

People compare the build price against the subscription. That is the wrong comparison, because it ignores the largest cost of buying imperfectly: the workaround.

Every product that nearly fits generates manual steps. Someone re-keys data between two systems. Someone exports to a spreadsheet each Friday. Someone checks the thing the software gets wrong. Those hours are real and they are permanent.

Cost them honestly. Four hours a week at a loaded cost of around £30 to £45 an hour is roughly £6,000 to £9,000 a year — every year, rising with wages. That is the figure that belongs opposite the build price. Once you include it, a £20,000 build that removes the workaround entirely frequently pays back inside three years, and the licence fee turns out to have been the small number all along.

Why seat count usually decides it

Per-user pricing has a property that catches growing companies out: your software bill scales with hiring, while a custom build does not.

At ten users on a £40 per-seat product you are paying about £4,800 a year — £14,400 over three years. Against a £15,000 build plus roughly £7,000 of maintenance, buying is sensible and building carries risk for no clear gain.

At forty users the same product is about £19,200 a year, or £57,600 over three years. The build has not got more expensive. That is why companies that were right to buy at ten people are right to build at forty — and why the decision deserves revisiting rather than settling once.

Before you sign: check who owns the code

This surprises people, so it is worth stating plainly. Under UK law the default position is that the developer or agency owns the copyright in software they write, even though you paid for it, unless the contract assigns it to you in writing. Employees are the exception. Contractors and agencies are not.

If you are building precisely to escape vendor lock-in, discovering afterwards that you licensed rather than own the result defeats the entire exercise. Ask for an explicit IP assignment clause and read it before work starts.

The disclosure

I build custom software for a living, so weigh the following accordingly.

Most businesses that ask me to build should buy instead, and I tell them so. The subscription you resent is almost always cheaper than the maintenance you cannot escape. Build when the thing you need genuinely does not exist, when three years of licences would exceed owning it outright, or when the process is your actual advantage.

And when you do build, build so it survives the person who built it. I grew an app agency from myself to 100 staff and sold it in 2015 — the entire job was making something that ran without me. The same principle applies to one internal tool.

Common questions