Build or buy, and the honest test between them

We build custom software. That makes us the wrong people to ask whether you need custom software, so it is worth setting out the test we actually apply rather than asking you to trust the conclusion.

The test

Is this process a real difference in how you compete, or is it an ordinary process you happen to do in a particular way?

Almost every business believes its processes are unusual. Most of the time what is unusual is the accumulated detail rather than the shape: you invoice like everyone else, with four exceptions that grew out of decisions made years ago and are no longer defended by anybody.

Ordinary processes should be bought. A product has thousands of businesses paying for its maintenance, its security patching and its compliance updates, and you get all of that for a licence fee. Building your own version means funding all of it alone, forever.

Genuine differences are worth building, because no product will support the thing that makes you better than your competitors, and bending one to fit is usually worse than starting from a blank page.

What buying actually costs you

The licence, obviously. Then two things that get left out:

Process compromise. You will change how you work to match the product, in a dozen small ways. Usually fine, occasionally not. The question is whether any of those compromises touch the thing you are actually good at.

Being one customer among thousands. Your feature request is a line on a roadmap you do not control, and a vendor decision can remove something you depend on.

What building actually costs you

The build is the smallest part, which is the thing most people get wrong.

You take on the maintenance forever. Security patching of dependencies, platform upgrades, browser changes, integrations that shift underneath you. Software is not an asset that sits still; it decays if nobody touches it. Budget for the running cost or do not start.

You also take on the knowledge risk. If one person understands it and leaves, you have a system nobody can safely change. That is manageable with documentation and code review, and it has to be deliberate.

The middle answer, which is usually right

Buy the platform, build the edges.

Run your ordinary processes on a product, and write the narrow piece that is genuinely yours against its documented interfaces. That way the invoicing, the ledger and the stock ledger are somebody else’s problem to maintain, and the thing that makes you different is yours.

That is why a lot of our development work is not standalone applications. It is a module extending an ERP, a field application feeding a system of record, or an integration making two products behave as one. Smaller surface area, less to maintain, and the parts you did not need to own stay unowned.

The questions worth asking before either

• Have you looked properly? Not a web search. Specifically, has anyone checked whether an industry-specific product exists for your sector, because for marine, packhouse and processing operations they often do.
• What happens if you do nothing? Sometimes the honest answer is that the spreadsheet is adequate for another two years, and the money is better spent elsewhere.
• Could a process change remove the requirement? The cheapest software is the software you did not need.
• Who owns it afterwards? If the answer is nobody, buy.
• If you build it, who else could maintain it? Documented interfaces, standard tooling, no exotic dependencies, and a repository you own. If we build something and you later want somebody else to look after it, that should be possible without ransom.

And the declaration

We would rather tell you to buy something and do the integration than build you an application you will still be paying to maintain in year six.

Not out of virtue. Because the alternative is a client who quietly resents a system they cannot leave, and we are trying to still be here in year six.