Custom software vs off-the-shelf: how to actually decide

Put as build-or-buy, this is a bad question, because it assumes one answer covers the whole business. Almost no operation we meet needs that. What they need is a line drawn in the right place between the parts that are genuinely standard and the parts that are the reason the company wins work.

Where off-the-shelf wins outright

Some problems are solved. Payroll, accounting, email, payments, document storage, video calls. These are regulated, commoditised, or both, and the packaged products are better than anything we could justify building for one client.

The test is whether your version of the problem differs from everyone else's in a way that matters commercially. Your payroll is not a competitive advantage. Nobody chooses you because of how you file VAT. Buy those, integrate them, and spend the attention elsewhere.

If a process is identical across every company in your sector, buying it is almost always right. The moment it stops being identical, the arithmetic changes.

Where packaged software quietly fails

Packaged systems encode an idealised version of a business. Every sale goes through the till. Every return comes back the same day. Every transfer is logged the moment it happens. Real operations have staff purchases, damaged goods, and a delivery signed for at the back door during a rush.

A packaged product handles the happy path well. What it does with your exceptions decides whether it works. Usually one of three things happens, and all three are expensive:

• People work around it. The exception gets recorded in a spreadsheet, a WhatsApp group or somebody's head, and the system's numbers slowly stop being true.
• The process bends to the software. Steps get added that exist only to keep the system happy. Nobody can explain them to a new starter.
• It gets customised. Consultancy days, a modified version you now cannot upgrade cleanly, and a dependency on whoever did the work.

The third is the one that looks like a solution and behaves like a liability. A heavily customised package is a custom system with none of the ownership and all of the licence fees.

The real cost of "we will just configure it"

Configuration is presented as the cheap middle path, and for a handful of fields it is. The problem is that configuration budgets are set against the demo, and the demo never includes the exceptions.

Before committing, make somebody walk the three worst days of your year through the product. Not the standard order — the disputed delivery, the part substitution approved verbally, the customer who pays on different terms because of something agreed in 2019. If the answer to any of them is a workaround, you have found the real scope.

The hybrid answer most operations need

The instinct to replace everything is usually wrong. Most operations run three or four systems, and typically one of them is genuinely good — the accounting package that works, the machine that talks to its own software, the payment service doing its job properly.

Ripping those out for the sake of tidiness costs a year and buys nothing the business can feel. The shape that tends to work is a custom layer where the operation is distinctive, integrated with packaged products where it is not, with one place that holds the truth about what you have, what you owe and who did what.

That is less impressive as an architecture diagram and much shorter as a path to the first release that matters. It is how we approach most ERP and platform work, and the integration side of it runs through nearly every industry we build for.

A test you can run this week

For each major process, answer two questions and plot the result.

1. 01Does doing this differently win or lose us work? If a customer would notice, or a competitor could not copy it easily, it is distinctive.
2. 02How often does the exception path run? Weekly or more means it is not an exception. It is part of the process that nobody wrote down.

Distinctive and exception-heavy is where custom pays for itself. Standard and clean is where you buy. Standard but exception-heavy usually means the process needs fixing before any software is chosen. Distinctive but clean is the one worth revisiting in a year, because it tends not to stay clean.

What to decide first, whichever way you go

Both routes need the same groundwork, and it is the groundwork that is usually skipped: where the truth lives. One data model, one permission structure, one audit trail. The moment a second system also claims to know what you have in stock, you no longer have a system of record. You have a reconciliation habit.

Settle that before you evaluate a single product or brief a single developer. If you are leaning towards building, how to write a software scope is the next step. If you are leaning towards buying, the same document is what you should be scoring vendors against.