Five Times You Should Not Build Custom Software

An awkward article for a software company to write

We build custom software. We also turn down projects, and the reasons are consistent enough to be worth writing down — partly because the projects that should not have been built are the ones everyone remembers badly.

If any of the five below applies to you, the honest answer is not to build, and any supplier who tells you otherwise is selling rather than advising.

1. An off-the-shelf product covers most of it

If an existing product does 80% of what you need for a few hundred pounds a month, building a bespoke version is difficult to justify. You would be spending five figures to gain the last 20% and taking on maintenance forever.

The exception is when that 20% is the part that makes you money. Automating your differentiator is worth building; automating something everyone does is worth buying.

Adapt your process to the product where the process is not itself an advantage. That is not defeat, it is economy.

2. The process is still changing

Automating a moving target wastes the build. If the team is still arguing about how something should work, encoding one version in software just makes the argument more expensive and slower to resolve.

Run the process manually until it stabilises for a few months, then automate what survived. The delay costs less than building twice.

3. Nobody will own it

Custom software needs an owner: someone who handles questions, decides on changes and notices when it drifts from what the business needs. Without one, it degrades quietly and is abandoned within two years.

If you cannot name that person before the project starts, that is the finding. Buy something with a vendor behind it instead.

4. The volume does not justify it

Automating a task done four times a week rarely pays back, however irritating the task is. Emotional cost and financial cost are different things, and it is worth being clear which one is driving the project.

Do the arithmetic before the enthusiasm: hours saved a year, times a fully-loaded rate, against build plus three years of maintenance.

5. The real problem is organisational

Some problems presented as software problems are actually about unclear ownership, misaligned incentives or a decision nobody wants to make. Software will not fix any of those, and it will absorb the energy that might have.

• “Nobody updates the system” is usually about incentives, not interface
• “Departments have different numbers” is often about definitions, not integration
• “Approvals take weeks” is frequently about authority, not workflow tooling

Building software around an organisational problem produces an expensive record of the dysfunction.

What to do instead

Buy something and adapt. Automate one narrow piece rather than the whole process. Fix the organisational issue first. Or do nothing for six months and see whether the problem is still the problem — a surprising number are not.

Any of those is a better outcome than a five-figure system nobody uses, and a supplier willing to say so is worth keeping the number of.

Frequently asked questions