Buy, build, or bend: how to decide without wasting a year

Every business that outgrows a spreadsheet arrives at the same three options. Buy something off the shelf. Build something bespoke. Or bend the way you work until it fits the software you already have.

Most companies try them in that order, which is sensible. What is less sensible is the test they use to decide when to move on, which is almost always some version of "how frustrated is everyone?" Frustration is a lagging indicator. By the time it is loud enough to trigger a decision, you have usually spent a year working around a problem that could have been fixed in six weeks.

Here is a better test.

Start by separating the two kinds of process

Every business runs on two categories of process, and they need opposite treatment.

Generic processes are the ones you do the same way as everyone else. Payroll. VAT returns. Email. Holiday requests. There is no competitive advantage available here, and there is no prize for doing it your own way. Buy these. Buy the boring, well-established, widely-used product, and change your process to match it.

Distinctive processes are the ones where the way you do it is the business. The particular way you quote a job. The specific sequence of checks before something ships. The rules that determine which customer gets which price. These are usually the things a new employee takes longest to learn, and the things your customers would notice if you stopped doing.

The mistake is treating both categories the same way. Companies buy generic software and then spend a fortune customising it to handle their distinctive process badly — or, worse, they change the distinctive process to fit the product, and quietly throw away the thing that made them worth choosing.

The bending test

Bending — adapting how you work to fit the software — is genuinely the right answer more often than software people like to admit. It is free, it is fast, and it removes complexity rather than adding it.

It stops being the right answer at a specific and identifiable point: when the workaround needs a person to remember it.

A workaround captured in the software is a design decision. A workaround that lives in somebody's head is a liability with a resignation date attached. When you hear "oh, you have to also update it in the other system, everyone knows that" — that is the signal. Not frustration. That.

Once a process depends on human memory to stay correct, the cost is no longer the inconvenience. It is the errors you have not found yet.

When buying stops working

Off-the-shelf software fails in a predictable pattern, and it is worth recognising the stage you are at.

Stage one: configuration. You set it up to match your needs. This is normal and healthy; it is what the product is for.

Stage two: workaround. The product cannot quite do something, so you use a field for a purpose it was not designed for. Everyone still copes. The "Notes" field starts carrying meaning.

Stage three: parallel system. Someone starts keeping a spreadsheet alongside the product, because the product cannot answer a question the business needs answered weekly. This spreadsheet becomes load-bearing without anyone deciding that it should.

Stage four: integration tax. You are paying someone — an employee, or a consultant on a retainer — to move data between systems that will not talk to each other, and to reconcile them when they disagree.

Stages one and two are fine. Stage three is a warning. Stage four is where buying has already failed and you are paying for it monthly without having made a decision. The annual cost of that integration tax is often startlingly close to the one-off cost of fixing it properly, and nobody has ever put the two numbers next to each other.

Do that. Put the two numbers next to each other. It is usually the entire decision.

When building is genuinely wrong

Bespoke software is not a status symbol and it is not a default. It is wrong when:

• The process is generic. If you are considering building your own accounting package, stop.
• You cannot describe the current process. If nobody can explain how it works today, building software to automate it will produce a faster version of the confusion. Map it first — that exercise alone frequently removes the need for the software.
• The pain is organisational, not technical. Two departments that will not agree on a definition of "customer" will not be reconciled by a database. The software will simply make the disagreement more expensive and more visible.
• Nobody will own it. Custom software needs someone inside the business who cares whether it is right. Not a technical person necessarily — but someone whose job gets better when it works.

What building actually costs

The build is rarely the expensive part, and that surprises people. The expensive parts are:

Deciding what it should do. This is where projects are won or lost, and where a good supplier spends much more time than clients expect. If someone quotes you a build without wanting to understand the business, they are quoting a guess.

The last ten per cent. Edge cases, the customer who is always an exception, the thing that happens once a quarter. This is where off-the-shelf products give up and where bespoke earns its price — but it is real work, and any estimate that ignores it is fiction.

Running it afterwards. Software is not a capital purchase that sits there depreciating. It needs updating, monitoring, and occasionally fixing at inconvenient times. Budget for it deliberately rather than discovering it.

A practical way through

If you are somewhere in the middle of this and cannot see clearly, the sequence that works is:

1. Write down what actually happens. Not the official process — the real one, including the workarounds. This takes a couple of days and is worth having whatever you decide next.
2. Mark each step generic or distinctive.
3. For the generic steps, buy the most boring, most established product available and adapt to it.
4. For the distinctive steps, ask what it currently costs you to keep them running by hand — including the errors, and including the risk that the person who knows how it works leaves.
5. Compare that to the cost of building it properly, once.

Most of the time the answer is a hybrid: buy the commodity, build the distinctive part, and connect them. That third piece — the connecting — is the one nobody quotes for and everyone needs.

If you would like a second opinion on which category your problem falls into, tell us what isn't working. We will say honestly if the answer is that you should buy something instead.