Build or buy? A decision rule for business software

A traditional IT provider has one answer to a business problem: recommend a product. Most of the time that is right. Some of the time the product doesn't quite fit, the business bends around it, a spreadsheet appears, and the problem lives on as a ticket for years.

The alternative is not "build everything". It is having a second answer available, and a rule for when to use it.

The rule

Ask three questions in order.

1. Is the process specific to how we work, or the same as everyone else's? Payroll, accounting, email, CRM, e-signature: the same as everyone else's. Buy, configure properly, integrate. Anything you build here will be worse than the market leader and cost more to keep.

2. Is the gap a missing integration rather than a missing product? "Our CRM and our back office don't talk to each other" is not a reason to replace either. It is a reason for an API, a sync or a workflow. Integration is the cheapest form of engineering and the most under-used.

3. Does the remaining gap change how we make money or how our clients experience us? If the process is genuinely yours, no product fits, and it touches revenue or the client, that is the case for building. A customer portal that does exactly what your clients need. An internal tool for the process your competitors don't have. A data platform that joins the six systems and finally answers the question the board keeps asking.

If you get to question three and the answer is "no, it's just annoying", buy the closest product and live with it.

What building has to include

If you do build, the software has to be built to be operated, not handed over. That means:

• It runs on infrastructure someone engineers and monitors, with backups and recovery.
• It sits on your identity, under the same security controls as the rest of the estate.
• Source, data and hosting configuration are in your name.
• Someone is accountable for it after go-live, under the same terms as everything else you run.

The agency model, build and hand over, is how businesses end up with a system nobody can change and a developer nobody can reach.

Where AI changes the sums

Two things have moved. Custom software is cheaper to build than it was, because a lot of the routine code is now generated and reviewed rather than typed. And a class of problems that used to need a person's judgement, reading a document, classifying a request, drafting a response, can now be a step in a workflow, with a model doing that step under rules and approval.

That does not change the rule. It changes where question three lands: more gaps are worth closing, and the "just annoying" ones are increasingly worth automating rather than tolerating.

The honest failure modes

Building when buying was right: an expensive, worse version of a product. Buying when building was right: years of bending the business around the tool. Building and handing over: a system with no owner. The rule exists to avoid the first two; operating what you build avoids the third.