Buy it, build it, or fix what you have

Three options are available for nearly every software problem a business has. Buy something that already exists. Build something specific. Or fix the thing that is already in use. Most quotes price exactly one of them, and it is usually the one the person quoting sells.

Here is how we decide, including the cases where we tell somebody not to hire us.

Buy, when the problem is not only yours

Accounting, payroll, email, document storage, a point of sale in a shop selling ordinary things. Thousands of businesses have the identical problem, somebody maintains an answer to it full time, and the version you buy has been tested by everybody who bought it before you.

You are not only buying features. You are buying updates when the tax rules change, a support line, and the fact that nobody at your business has to think about it again. Custom software has none of those unless you pay for them separately, which is the cost people forget when they compare a monthly subscription against a one-off build.

Fix, when one part of it is wrong

This is the most common honest answer and the least common quote. A business asks for a new system, and the audit finds nothing much wrong with what is in place except one workflow it does not cover. A spreadsheet grew beside it to handle that workflow, then a second one to reconcile the first, and after two years the whole thing feels broken.

Fixing that is a fortnight of work: an export, an import, a small piece of software connecting two things that were never connected, or in some cases a settings change and an afternoon of training. It is the cheapest of the three options by a wide margin, and it is worth ruling out before anybody draws a new system.

Build, when the process is the business

Custom earns its cost in one situation: your way of working is either the reason customers choose you, or unusual enough that no package models it without a spreadsheet appearing alongside. Distribution with different credit terms per customer. A school billing termly with instalments and part payments. A workshop quoting from parts and labour where the parts price moves weekly. A clinic that has to keep records for years in a specific form.

In each of those the package either does not model the thing at all, or models it in a way that means somebody keeps a private copy of the truth. Then you have two systems instead of one, which is worse than the situation you started with.

The test that settles most cases: if you changed the process to fit the package, would you be worse at the thing you are good at? If the answer is no, change the process. It is much cheaper and there is nothing embarrassing about it.

The costs that are not on the quote

• Migration. Data that lives in four places has four spellings of the same customer name, and deciding which one is right is a business decision, not a technical one. It always takes longer than the estimate.

• Integration. Two systems that do not talk to each other produce a person whose job is partly retyping. That salary belongs in the comparison.

• The dip. Output falls for a fortnight after any change, whichever option you pick. Plan for it rather than being surprised by it in the middle of a busy month.

• The second year. A licence renews. Custom software needs hosting, updates and somebody to ring. Compare three years, not the first invoice.

Five questions that usually decide it

1. Can you name three other businesses with exactly this problem? If you can, somebody is already selling the answer.

2. Is this process the reason customers choose you, or is it just how it has always been done here?

3. What does the current situation cost in a month, counted in hours and in mistakes? If you cannot answer, measure that before spending anything.

4. How many people need it at the same time, and are they in one building? Two people and one building is a much smaller problem than twenty and four.

5. If the supplier disappeared in two years, what would you do? The answer changes both the choice and the terms you should be asking for.

The answer is usually a mixture

Buy what is standard, build what is specific to you, and connect the two so that nothing is typed twice. That is what most of our software development work looks like in practice, and it is why the first conversation is about the process rather than about the software.

We say no to builds fairly often, and it is not modesty. A build that should have been a settings change is remembered as an expensive year. If you want the question answered before it becomes a quote, that is where an IT consulting engagement starts: tell us what the process is and what is currently in the way.