The price on the invoice is the smallest number in the life of a piece of software. What a business actually pays is spread across the years afterwards: the hours spent working around what the system cannot do, the second tool bought to patch the first, the person whose job quietly became “keeping the spreadsheet in sync”. None of that appears on a budget line, which is why it is so rarely counted.
This matters because the cheapest-looking option is chosen on the number that is easiest to see. A subscription at forty pounds a month beats a custom build on day one, every time. It loses by year three, and by then nobody is comparing, because the cost has dissolved into the way people work.
Three kinds of cost
Most conversations about software cost stop at the first of these. The other two are where the money goes.
The cost to build
The visible one. Design, engineering, testing, deployment. It is a real number and it deserves scrutiny, but it is bounded: it happens once, and a competent estimate lands within a known range. It is also the only one of the three that a business ever negotiates.
The cost to operate
Hosting, licences, monitoring, the occasional dependency upgrade. Small per month, easy to forget, and cumulative. A system that costs little to build and a lot to run is a common shape, and usually a mistake. So is the reverse when the business is small: an expensive build that saves a few pounds a month never repays itself.
The cost to work around
The invisible one, and the largest. Every gap between what the system does and what the business needs is filled by a person. They copy figures between two tools. They keep a parallel list because the official one cannot be trusted. They answer the same question by hand because the system cannot. Multiply an hour a day by the people doing it and by the years the system survives, and this number dwarfs the other two.
A system is cheap when it removes work. It is expensive when it merely moves work somewhere the budget cannot see.
A worked comparison
The table below is illustrative. The magnitudes are typical; the shape is the point.
| Cost | Off-the-shelf tool | Custom system |
|---|---|---|
| Build | low | higher |
| Operate, per year | medium | low |
| Work around, per year | high | low |
| Five-year total | highest | lowest |
The pattern repeats across businesses of very different sizes: the option that looks cheapest on day one costs most by year three, because it was never designed for the way the business actually works. A generic tool is built for the average of a thousand companies. No company is the average.
The sequence a system has to complete before it pays for itself: the problem it removes, the system that removes it, the change in how people work, and the outcome the business can count.
What to count instead
- Hours removed. How many person-hours a week does the system take away, for good? This is the only number that matters in the long run, and it is the one most proposals never state.
- Hours added. Every system adds some: learning it, feeding it, checking it. Count these honestly and subtract them. A system that needs constant feeding is a job disguised as a tool.
- Decisions improved. Harder to price, but real: a system that surfaces the right thing at the right time changes what people do next, and that shows up in the revenue line eventually.
- What it makes possible. The offer a business could not make before because the operation could not support it. This is where custom systems earn their build cost several times over.
Put those four against the build cost and the operating cost and the picture changes. Software stops being an expense to minimise. It becomes the mechanism by which a business decides how much of its own time it wants to spend on things a machine could do.
Where this leaves a buyer
Ask for the five-year number, not the quote. Ask what the people who use it will stop doing. Ask what they will start doing instead. Ask what happens when the business is twice its current size, because the system will still be there. A vendor who cannot answer those questions is selling software. One who can is selling a system.