Software rots even when you don't touch it — the maintenance question nobody asks before they build

The pitch for custom software almost always ends at launch. You sign off, the system goes live, everyone celebrates, and the invoice closes. Then a quiet assumption settles in on both sides of the table: the thing is done. It works today, so it will work next year. That assumption is the single most expensive misunderstanding in this business — because software is the one asset that decays while sitting perfectly still.

Nothing in your code changes, but everything around it does. A browser ships an update. A payment provider deprecates an interface. A phone operating system drops support for an old component. A tax rule changes. A dependency you have never heard of publishes a security advisory at two in the morning. None of that touched your business logic — and all of it can break your system, or quietly open a hole in it. A system is not a building you finish and hand over the keys to. It is a garden, and gardens grow whether or not anyone is tending them.

This piece is about the half of the cost that lives after launch: what maintenance actually is (mostly not bug-fixing), why every living system needs it, what neglecting it costs in security and slow decay, and how to decide who owns that responsibility before you commission the build — rather than the morning something goes down and nobody can say whose job it was to stop it.

The number that surprises every first-time buyer: across a system's life, the original build is the smaller part of the bill. The discipline has converged for decades on a simple rule of thumb — maintenance runs 60 to 80 percent of total lifecycle cost, captured in the well-worn "60/60 rule": about 60 percent of what a system costs over its life is maintenance, and about 60 percent of that maintenance is enhancement, not repair ^[1]. Read that twice. The build you are negotiating is the down payment on a larger, longer obligation — and most of that obligation is making the system do more, not fixing what broke.

This is not an opinion; it is close to a law of the medium. Decades ago, studying how large systems evolve, Lehman set down what are now called the laws of software evolution. The first — Continuing Change — holds that any system embedded in the real world must keep changing or it becomes progressively less useful. The seventh — Declining Quality — holds that the quality of that system will appear to fall unless it is rigorously maintained and adapted to its environment ^[2]. The implication is blunt: a system you stop investing in does not hold steady. It slides. Standing still is a direction, and it points down.

It helps to be precise about what "maintenance" even means, because the word makes owners picture repair. The international standard for the software life cycle splits it into four kinds: corrective (fix the defects you found), adaptive (keep working as the surrounding world shifts), perfective (improve and extend what users now ask for), and preventive (harden latent weaknesses before they bite) ^[3]. Only the first is "fixing bugs." The other three are about staying alive and useful in a world that will not stop moving — and they are where most of the work lives.

Here is the part that overturns the intuition: bug-fixing is the smallest slice. The classic survey of how maintenance effort is actually spent found the lion's share goes to perfective and adaptive work — roughly 60 percent on improvement and new capability, under a fifth on correcting defects, and the rest on keeping pace with a changing environment ^[4]. So when someone says "we don't need a maintenance budget, the system has no bugs," they have misread the job. Maintenance is not the penalty for having built it badly. It is the running cost of the system still being wanted.

Skip it and the bill does not disappear — it moves, and it moves to the worst possible line. The clearest example is security. Your code can be flawless and still become dangerous, because the danger arrives from outside it: a component you depend on ships a newly discovered vulnerability, and the clock starts. The most recent large-scale breach analysis found that exploitation of known vulnerabilities as the way into a breach jumped about 180 percent in a single year, and that organisations take on the order of 55 days just to patch half of their critical, already-fixed flaws ^[5]. The disclosure rate itself is now relentless — the public vulnerability catalogue is logging well over a hundred new entries every day ^[6]. An unmaintained system is not frozen in its launch-day safety. It is sitting still while the threats around it compound daily.

None of this argues for the loudest, most expensive maintenance contract on the menu. It argues for naming the responsibility before you build, not after something breaks. The expensive failure mode is the orphaned system: commissioned, launched, celebrated, then left with nobody whose actual job is to watch the dependencies, apply the patches, and absorb the small adaptive changes the world demands every quarter. The maintenance question — who owns this in month thirteen — is cheap to answer at the kickoff and brutally expensive to answer in the middle of an outage. Ask it first.