Custom Software vs Off-the-Shelf: How to Choose

Build or buy is usually presented as a matter of budget. It is really a question about fit: how closely your process matches the process the product was designed around, and what the mismatch costs you every week.

Get that right and the financial comparison mostly answers itself.

The comparison, honestly

	Off-the-shelf	Custom
Time to running	Days to weeks	Weeks to months
Cost shape	Recurring, per seat	Larger up front, lower ongoing
Fit to your process	Good where you are typical	Built to what you do
Changing it	Request it, and wait	Scheduled work
Your data	In the vendor’s model	In yours
Maintenance	Included	Yours to budget
Risk if the supplier disappears	You must migrate	You hold the code
Best when	The process is standard	The process is yours

Nothing in that table makes one option correct. It shows where each one is strong, and the honest answer for most businesses is a mixture: buy the standard things, build the distinctive one.

Start with the fit question

Before any conversation about price, answer this: how much of your process does the product actually cover?

Not “could we make it work”, because nearly anything can be made to work. The question is what is left over. Write down the steps the product does not handle, and be specific about who does them instead and how often.

That leftover list is the entire decision. If it is short and involves nothing important, buy the product. If it contains the bit that makes you money, or a weekly export somebody maintains by hand, you are looking at the real cost of the package, and it is not the licence fee.

What a package genuinely gives you

It is worth being fair to the option people often dismiss too quickly.

It exists now. You can be using it this week. For an urgent problem, that can outweigh everything else.

Somebody else maintains it. Security patches, browser changes, new regulations. That work happens whether or not you think about it.

It has been used by thousands of others. The obvious bugs have been found. The edge cases have been hit by somebody before you.

It is predictable. A known monthly figure is easier to budget than a project.

There is an ecosystem. Documentation, training, people who already know it, integrations that exist because enough customers asked.

For anything standard, such as accounting, payroll, email and general-purpose CRM, these advantages are decisive, and building your own version is a mistake dressed up as independence.

Where a package quietly costs more than it charges

The licence is visible. These are not, which is why they are so often left out:

Configuration that never quite finishes. Weeks of setup, then a consultant, then a partial fit that everyone stops complaining about because complaining achieved nothing.

The workaround with a person in it. Most poor fits end up with somebody exporting, reconciling or re-entering. That person’s time is the real cost and it recurs forever. Cost it at their actual hourly rate and it usually dwarfs the subscription.

Seats you pay for at full price for partial use. Ten users who need one screen still cost ten seats.

Waiting. When the business needs a change and the answer is that it is on a roadmap, the cost is the delay, not the fee.

Data you cannot get at. Reporting limited to what the vendor exposed, and an export in a shape nobody wanted.

We set out how to put numbers against these in what custom software costs in the UK.

Where custom is the weaker choice

Equally worth saying plainly.

When the process is genuinely standard. If what you do is what everyone does, you are paying to rebuild something that already exists and is better tested.

When you need it immediately. A build takes time. If the problem is on fire, a package now beats the right answer in two months.

When nobody can own it. Custom software needs someone internally who decides what changes next. Without that, it drifts into the same not-quite-fitting state you were trying to escape.

When the requirement is not settled. If the process is actively being redesigned, building software for it is premature. Work out the process first, which a spreadsheet is genuinely good for.

When the budget only covers the build. A build with no maintenance budget is a liability with a launch date.

The middle ground most businesses land on

The framing of build-or-buy as a single decision is usually wrong. The practical pattern is:

Buy the commodity. Accounting, payroll, email, document storage. Solved problems, solved well.
Build the distinctive. The process specific to your business, the one your competitors do differently and your customers notice.
Connect them. The build reads from and writes to the packages rather than replacing them.

This keeps the project small, which is the single best predictor of it working. It also means the expensive custom work is spent only where it buys something a product cannot.

A short decision test

Answer these about the process in question:

Would a competitor’s version of this process look the same as yours? If yes, lean towards buying.
Is there a product that covers it without a manual step? If yes, buy it.
How many hours a week go into the gap between the product and what you need? Multiply by a rough hourly cost, then by 150 weeks. Compare that to a build.
What happens if it stays as it is for three more years? If the answer is “the same, but more of it”, the cost is already being paid.
Who would own the software afterwards? If nobody, fix that before deciding anything.

Questions three and four are the ones that change minds, because they convert a vague irritation into a number.

If you decide to build

Start narrower than feels satisfying. One process, done properly, connected to what exists. It proves the approach, it produces something useful early, and it gives you a real basis for pricing whatever comes next.

Who builds it matters at least as much as the decision to build, and there are things worth checking before you commit.

If that process is currently a spreadsheet, that is the most common and most tractable starting point of all, and it comes with its own warning signs, which we have set out in seven signs a business has outgrown its spreadsheets.