Most software budgets are built around the wrong milestone. They treat the day the thing goes live as the finish line. It is the start line.
The build is a big, visible number, so it gets all the attention. It is easy to plan for, easy to sign off, and it has a clear end. The years that follow are none of those things, which is exactly why they get left out of the budget. Then, eighteen months later, something breaks, or the business needs a change the original build never anticipated, and the cost of the neglected years arrives all at once.
This is not an argument for spending more. It is an argument for spending in the right shape. Planning for the run-and-improve years from day one is almost always cheaper than the rescue-rebuild that follows years of leaving a system alone.
Shipped software still degrades
A common assumption is that once software works, it keeps working. Physical things wear out; code just sits there. So surely, once it is done, it is done.
It does not work like that, and the reason is that your software does not live in isolation. It sits on top of a stack of other people’s software that keeps moving underneath it.
Three things happen to every system after launch, whether anyone touches it or not.
Security patches
New vulnerabilities are found in the libraries, frameworks and servers your product depends on, every month. Keeping up is a running job, not a one-off. A system nobody is patching is not stable, it is accumulating known holes that anyone can look up.
Dependency rot
Modern software is assembled from hundreds of external components. Those components get new versions, and the old versions stop being supported. Leave it long enough and you cannot make even a small change without first doing a large, expensive catch-up, because everything you depend on has moved on without you.
Changing business needs
This is the big one, and it is a good problem to have. Your business will not stand still. You will add a service, change how you price, enter a new market, or respond to a competitor. Every one of those needs the software to change with it. Software that cannot keep pace with the business becomes a brake on it.
None of this is a sign anyone did a bad job on the build. It is simply what happens to anything connected to the wider world and left unattended.
The hidden cost of build-and-abandon
The build-and-abandon model looks cheaper because the second cost is invisible at the point you decide. You pay for the build, the invoices stop, and for a while nothing goes wrong. It feels like a saving.
What is actually happening is that risk is building up out of sight. The security gaps widen. The dependencies drift further from anything current. The list of small changes the business wanted but never got round to grows into a backlog. The people who built it move on and take the knowledge of how it fits together with them.
Then something forces the issue. A security incident, a supplier who pulls support for a version you are stuck on, or a change the business simply cannot operate without. Now you are not making a small adjustment to a healthy system. You are trying to work on something that has drifted so far it often costs more to rescue than it would to rebuild from scratch.
That is the real trade. The choice was never “spend on aftercare” versus “spend nothing”. It was “spend steadily and stay in control” versus “spend nothing now and pay a much larger, less predictable bill later, at the worst possible time”.
The most expensive question in software is the one nobody wants to be asking: who answers the phone in month 14, when the thing that runs part of your business stops working and the people who built it are long gone.
What a good maintenance relationship actually buys
Aftercare has an image problem. It sounds like an insurance policy you resent paying for, or a support desk that closes tickets. A good one is neither. It buys you three things that matter to the business, not just to the software.
The first is that the system stays current and secure without you having to think about it. Patches get applied, dependencies get kept up to date, and problems get caught before they become incidents. The value here is the absence of a crisis, which is hard to feel until you have lived through the alternative.
The second is that the software keeps pace with the business. When you want to change how something works, add a feature, or respond to what the market is doing, there is a team who already understands the system and can make the change quickly, safely and cheaply. You are not re-explaining your business to a new supplier every time, or paying for someone to relearn a codebase from cold.
The third is a relationship with people who know your product and your business well enough to tell you what to do next. Over years, a good partner spots the improvement you have not asked for, the risk you have not seen, and the place where a small investment now saves a large one later. That judgement compounds. It is the difference between a supplier and a partner.
[PROOF POINT]
How to budget for it without a blank cheque
The fair worry about aftercare is that it turns into an open-ended commitment with no clear return. That is avoidable, and it is on your partner to make it clear rather than on you to police it.
A sensible arrangement does a few things. It sets aside a predictable amount for the essential running work, the security patching and dependency upkeep that has to happen regardless. It keeps a defined, agreed pot for improvements, so you are always spending against a priority list you control rather than a blank cheque. And it reports plainly on what was done and why, so you can see where the money went and decide what comes next.
The number that matters is not the monthly cost of aftercare. It is the total cost of owning the software over its life, and the size of the bill you are signing up for if you skip it. Budget for the whole life of the thing, not just the day it is born, and the run-and-improve years stop being a nasty surprise and become the cheapest insurance you buy.
Treating launch as the finish line is the single most expensive mistake in a software budget. Move the line, and everything after it gets cheaper and calmer.
If you are about to commission something new, or you have a system that has gone quiet and you are not sure who is looking after it, we are happy to talk it through. Book a free 30-minute call and we will give you a straight read on where the real costs sit and how to plan for them. No pressure, no pitch.