Every piece of business software you run is either being maintained or decaying. There is no third state. The app that "was finished" three years ago isn't finished — it's unmaintained, and the difference shows up on its own schedule, usually at the worst possible time.
The annual shift nobody budgets for
Apple and Google each ship a major OS release every year, alongside new hardware, new screen shapes and new security rules. Every one of those releases changes assumptions some existing code depends on. The consequences for an unmaintained app arrive in a predictable sequence: first cosmetic glitches on new devices, then broken features as deprecated APIs are switched off, then crashes — and eventually delisting, because both stores actively remove apps that haven't been updated against recent SDKs. An app that works perfectly today and receives no maintenance is, on a two-to-three year horizon, an app that doesn't exist.
It's not just mobile
Web software decays on the same clock with different hands: browsers evolve, TLS and security baselines move, frameworks and libraries publish vulnerabilities that must be patched, hosting platforms retire old runtimes, and every third-party API your system talks to will eventually change or die. "We haven't touched it in years and it still works" doesn't describe stability — it describes accumulated, uninspected risk with your business logic sitting on top.
Why the project model produces decay
None of this is a surprise to developers. Decay is built into the commercial model most software is bought under: a project is quoted, delivered, celebrated and closed. Maintenance is left to a future negotiation nobody wants to have — every patch needs a change request, small fixes can't justify the paperwork, and so nothing is touched until something breaks. The business hasn't bought software; it's bought a snapshot of software, depreciating from the day it ships.
What living software looks like
Treating software as a living asset means maintenance isn't an event — it's a rhythm. In our model that rhythm is contractual: every month, a production release goes out bundling feature work, optimisations, dependency updates and security patches, and every annual OS shift is absorbed as routine work rather than a crisis quote. The cost of keeping software alive this way is modest and predictable. The cost of the alternative arrives all at once, labelled "it needs a rebuild".
Three questions to ask about your own systems
- When was each app or system last deployed — not fixed, just deployed? If the answer is "months ago", nobody is maintaining it.
- Who is accountable, by name, for it still working after the next iOS and Android releases?
- If it broke on Monday, does anyone currently under contract have both the code access and the obligation to fix it?
If any answer is unclear, the software isn't finished — it's abandoned, and it hasn't told you yet.