When custom software is worth it (and when a spreadsheet is fine)

Somebody in your business does a job by hand every week that a computer could do. That does not, on its own, mean you should have software built. Plenty of manual processes are cheaper to keep manual, and plenty of custom systems have cost more than the problem they replaced.

Here is the test we actually apply before quoting.

Question 1: how much time does it really take?

Measure it for two weeks rather than estimating. Estimates of recurring admin are unreliable in both directions — people forget the small daily instances and over-remember the painful monthly one.

Then annualise it. Four hours a week is roughly five working weeks a year. That is the number the build cost has to be compared against, not the four hours.

Question 2: is the cost the time, or the errors?

Often the hours are affordable and the mistakes are not. Retyping order details into a second system takes six minutes; getting one digit wrong costs a wrong delivery, a refund and a customer. When the failure is expensive and the task is repetitive, the case for building is stronger than the timesheet suggests.

Question 3: does the process actually work?

Automating a broken process gives you a broken process that runs faster and is now harder to change. If nobody can describe the current rules without saying “it depends who is doing it”, fix the process on paper first. That step alone sometimes removes the need to build anything.

Question 4: has somebody already built it?

This is the question a supplier is least incentivised to ask, so ask it yourself. If an off-the-shelf product covers eighty per cent of what you need for a monthly fee, buying it and adapting your process is almost always cheaper than building the hundred per cent. Build when the thing that makes your business yours is precisely the part no product handles.

Question 5: how often do the rules change?

Rules that change quarterly want a spreadsheet or a configurable tool, not code that needs a developer every time. Rules that have been stable for years are safe to encode.

When the answer is clearly build

• The data already exists somewhere and the work is purely assembling it into a usable view.
• Several people need the same answer at the same time, and today it lives in one person's file.
• The manual step is the bottleneck on something you want to grow.
• A regulator, an auditor or a customer requires a report that currently takes days.

The console we built for a data centre estate is a clean example of the first two: every fact was already being produced by the hardware, and the only reason nobody had the answers was that collecting them by hand had stopped happening.

When the answer is clearly don't

• It happens twice a year.
• Only one person needs it, and they are content.
• You cannot write down the rules.
• You want it because a competitor has one.

Where AI changes the calculation, and where it doesn't

AI genuinely lowers the cost of some things that used to require custom code — extracting information from messy documents, classifying free text, drafting summaries. That moves a few projects from “not worth it” to “worth it”.

It changes nothing about the questions above. A process nobody can describe is not made describable by a language model, and a task done twice a year is not worth automating however cheap the automation becomes. AI is a component, not a reason.

How we scope it

We ask these questions before quoting, and we say so when the honest answer is that the build will not pay for itself. A referral or a “keep doing it by hand” costs us one project; a system nobody uses costs a reputation. Book a scoping call and we will tell you which one this is.