The invoice for building the software feels like the whole cost. Launch day feels like the end of the story. Both feelings are wrong, and the gap between them and reality is where a lot of otherwise good software quietly dies. Software is not a thing you buy once and own. It is a thing you keep alive, and the keeping-alive is not optional maintenance you can defer — it is the price of the software continuing to work at all.
Software is never actually finished
A launched product sits on a foundation that keeps moving underneath it. The libraries it depends on release new versions and abandon old ones. Security vulnerabilities are discovered in code you never wrote but rely on completely. The operating systems and browsers your users run change several times a year, and each change can quietly break something that worked yesterday. On top of that, real users find bugs your testing never reached, and the moment people use the thing they start needing small improvements nobody could have specified in advance.
None of this is a sign that something was built badly. It is the normal weather of running software. A product that ships and is then left untouched does not stay finished — it starts decaying from the day of launch, slowly at first and then all at once.
The comparison people reach for is a car or a building, and it is closer than it first appears. Nobody expects to buy a building and never spend on it again; there is a roof to check, systems to service, wear to stay ahead of. Software is stranger only in that its decay is invisible until the day it is not. Nothing looks worse from the outside as the neglect accumulates — right up to the moment something stops working entirely, at which point the cost of catching up has been quietly growing the whole time.
What maintenance actually covers
Maintenance is a bundle of distinct activities that get lumped under one word. There is keeping dependencies current, so the foundation stays supported and secure. There is applying security patches promptly, because a known vulnerability left open is an invitation. There is keeping pace with operating system and browser changes so the product keeps working on the devices people actually use. There is fixing the bugs that surface in real use, and there is the steady stream of small improvements that keep the software fitting the business as the business changes.
Notice that most of this has nothing to do with anything going wrong on your side. It is the cost of the world moving. You are not paying to fix mistakes; you are paying to stay still relative to a foundation that refuses to.
It helps to separate the reactive work from the quiet, preventive kind, because buyers tend to see only the first. Reactive maintenance is what everyone pictures — something breaks, someone fixes it. Preventive maintenance is the work that stops things from breaking in the first place: the dependency updated before it becomes unsupported, the patch applied before the vulnerability is exploited, the small refactor that keeps the code changeable. The preventive kind is cheaper, calmer and almost invisible, which is exactly why it is the first thing cut and the first thing missed.
What neglect actually costs
Skipping maintenance is not free — it is deferred, and it accrues interest. The first cost is security. Unpatched, out-of-date software is exactly what attackers look for, and a breach costs incomparably more than the maintenance that would have prevented it, in money, downtime and trust. The second cost is decay. Small unaddressed problems accumulate, dependencies drift so far out of date that updating them becomes its own project, and the software gets slower to change precisely when the business needs it to change fastest.
The third and largest cost arrives at the end of that road. Software left to rot long enough reaches a point where it cannot be safely updated at all, and the only path forward is an emergency rebuild — the exact expensive, disruptive project the original build was supposed to spare you, now forced on the business's worst timeline instead of its own. Neglect does not save the maintenance budget. It converts it into a far bigger one, later, with no choice about when.
What makes this trap so easy to fall into is that neglect is rewarded in the short term. The quarter you skip maintenance, nothing breaks and the money stays in the business, which feels like a good decision. The bill for that quarter arrives two or three years later, bundled with all the others you deferred, at a size that no longer looks like maintenance at all. By then the people who made the saving have often moved on, and the people holding the emergency never chose it.
What it typically costs to do right
Maintenance is best understood not as an occasional bill but as an ongoing share of what the build cost. As an illustrative frame rather than a quote, it is common for annual maintenance to run at a meaningful percentage of the original build cost — enough that it belongs in the budget as a recurring line, not a surprise. The exact figure depends on how large and complex the system is, how many external services it integrates with, how fast its foundations move, and how business-critical it is.
The number that matters is not the percentage itself but the fact that there is one, every year, for as long as the software lives. A partner who quotes a build cost and goes quiet about the ongoing cost has told you only half the price. The honest version names both, so you can decide with the real total in view rather than discovering the second half after you have committed to the first.
It is worth reframing this figure as insurance rather than expense, because that is closer to what it does. The annual maintenance spend buys down the risk of the large, unscheduled costs — the breach, the emergency rebuild, the outage during your busiest week. Seen that way, the question is not whether you can afford maintenance but whether you can afford to carry those risks uninsured. For most businesses running software they depend on, the recurring cost is the cheaper side of that trade by a wide margin.
Support tiers and SLAs in plain terms
Support is the human side of keeping software alive, and it is usually sold in tiers that come down to two questions: how fast will someone respond when something breaks, and how much attention is reserved for you. A basic tier might mean issues are handled during business hours within a day or two — fine for an internal tool where a pause is survivable. A higher tier means faster guaranteed response and cover outside business hours, which is what you need when the software failing means the business stops.
A service level agreement, an SLA, is simply that promise written down: the response times you are guaranteed and what happens if they are missed. The right tier is not the most expensive one. It is the one matched to what an outage actually costs you. Pay for the response speed your business genuinely needs, and do not pay for round-the-clock cover on a system that can wait until Monday.
The way to size the tier is to put a number on an hour of downtime for each part of the system. A tool your staff use internally might cost an afternoon of irritation. A system that takes customer orders or runs a production line might cost real revenue and reputation by the hour. Match the guarantee to that figure and the decision stops being a vague trade-off and becomes arithmetic — and you will usually find some parts deserve a strong SLA and others honestly do not.
Good support starts before anyone reports a problem
The best support is the kind that notices trouble before your users do. Waiting for someone to report that the system is down means your customers become your monitoring, and by then the damage — lost orders, lost trust — is already done. Proper maintenance includes watching the software in production: alerts when something starts failing, visibility into errors as they happen, and attention to the early signs that a dependency or a server is heading for trouble.
This changes the character of support from reactive to quiet. Instead of a scramble when everything stops, you get a small fix applied at a calm moment, often before anyone outside the team would have noticed. When you agree a support arrangement, ask not only how fast someone answers when you call, but whether they are watching at all when you are not looking. A partner who only reacts to reported problems is offering you half of what support means.
Who holds the knowledge, and budgeting from the start
There is a quieter risk underneath all of this: knowledge. Every system carries understanding that lives in the people who built it — why it is shaped the way it is, where the fragile parts are, how to change it safely. If that knowledge is not deliberately kept and documented, a maintenance contract becomes fragile, because the people who could honour it might move on and take the map with them. Ask any partner not just whether they will maintain the software, but how the knowledge to maintain it is retained.
All of this argues for one thing: decide how the software will be maintained and supported before you build it, not after. Budget the recurring cost from day one, agree who holds the knowledge, and match the support tier to what downtime really costs you. Software planned with its whole life in view is far cheaper over that life than software bought as if launch were the end. If you want a clear-eyed view of what keeping your software alive should cost, start with a call.