What Keeps Software Useful Over a Decade
Last updated:
Ten-year-old software can be excellent
We work on applications built a decade ago that are pleasant to change and entirely fit for purpose. We also work on three-year-old ones that are almost untouchable.
The difference is not the original quality. It is whether anyone has maintained them continuously.
The habits that matter
- Dependencies updated monthly rather than annually
- PHP version kept on a supported release, always
- Tests kept passing, not disabled when inconvenient
- Decisions documented as they are made
- Code improved where it is touched, not in a separate project
Deferred maintenance compounds. Each skipped update makes the next one harder, until a routine upgrade becomes a project.
A named owner
Someone in the business who knows what the application does, decides what changes, and notices when something is wrong. Not necessarily technical.
Applications without an owner drift: nobody notices the report that stopped, the integration that failed, or the process that changed six months ago.
Change it as the business changes
- A process change should trigger a system change, not a workaround
- Workarounds accumulate and eventually become the process
- Small changes made promptly are cheaper than large ones made late
- A system that no longer matches the business is worse than no system
Budget for its whole life
| Year | Typical spend |
|---|---|
| 1 | Build cost |
| 2–3 | 15–25% annually, maintenance and small changes |
| 4–6 | Similar, plus occasional larger changes |
| 7–10 | Similar, plus a modernisation at some point |
Budgeting only for the build is how businesses end up with a system nobody has touched in four years and a rewrite proposal they did not expect.
Frequently asked questions
How long should a business application last?
When is a rewrite genuinely needed?
Who should own it?
What if the original developer is gone?
Application nobody has touched in years?
It is probably still salvageable, and the longer it waits the less true that becomes. Happy to assess it.
Related services
What we build for problems like this one