People ask how long custom software takes to build. Far fewer ask how long it lasts — which is strange, because that number decides whether the investment made sense.
The short answer: well-built business software runs 8 to 12 years before a rebuild is genuinely justified, and badly-built software starts costing you money in year three. The gap between those two outcomes is not luck. It comes down to a handful of decisions made early.
Realistic lifespans by type
- Integration between two systems: 3–6 years. Its lifespan is set by the systems it connects, not by itself. When the ERP is replaced, the integration goes with it.
- Internal tool or dashboard: 5–8 years. Usually outlives its own expectations, because the process it supports changes slowly.
- Customer-facing portal: 4–7 years. Visual expectations age faster than the code. Often the interface is rebuilt while the back end continues.
- Line-of-business system (the thing the company runs on): 10–15 years, sometimes far longer. Rewriting these is expensive and risky, so they get maintained instead — which is the right call more often than vendors admit.
- Mobile app: 3–5 years before a significant rework. Apple and Google force this rhythm regardless of how good your code is.
These assume the software is maintained. Unmaintained, halve every number.
What actually ends a system's life
It is almost never that the code stopped working. Four things kill business software, in roughly this order of frequency.
The platform underneath moves on. Frameworks and language versions reach end of support, and at some point a security patch stops being available. This is predictable and cheap to handle if you keep up, and expensive if you skip five years and try to jump all at once.
The business changed shape. You added a second country, a new product line, a different pricing model. Software written around assumptions that no longer hold accumulates workarounds, and eventually the workarounds are the system.
Nobody understands it any more. The developer left, documentation was never written, and every change is now archaeology. This is the most common real cause, and the most preventable one.
Integrations rot. The payment provider deprecates an API version, the carrier changes their format, the accounting package moves to a new authentication scheme. Each one is small. Ignored for years, they compound.
How to tell where yours stands
A rough diagnostic. If three or more of these are true, you are on the back half of the lifespan:
- A small change takes weeks, and nobody can explain why.
- Nobody currently employed or contracted has read the code end to end.
- The framework or runtime version is past its official end-of-support date.
- There are manual steps that exist purely to work around the software.
- Deploying is scary enough that it happens rarely, which makes it scarier.
- There are no automated tests, so every release is manual verification.
None of those individually means rebuild. Together they mean maintenance cost is rising and will keep rising. Whether that justifies a rebuild is a separate calculation — rebuild or refactor works through it properly, and the answer is "refactor" more often than the person quoting you a rebuild would like.
How to buy software that lasts
Four things, decided at the start, that do more for lifespan than any technology choice:
Own the code and the infrastructure. In your repository, in your cloud account, from day one. Software you cannot move is software with someone else's expiry date on it.
Insist on tests and documentation as deliverables, not extras. A system with a test suite can be changed by someone who did not write it. A system without one cannot be changed safely by anyone, including its author, two years later.
Use boring, widely-known technology. The framework everyone knows has a larger pool of developers who can maintain it and a longer support horizon than the elegant niche one. For business software, boring is a feature.
Budget maintenance from the start. Roughly 15–20 percent of the build cost per year keeps dependencies current, integrations alive and small changes flowing. Skipping it does not save money — it defers it, at interest. What maintenance actually involves breaks that down.
The honest summary
Custom software is not a purchase with a warranty date. It is closer to a building: it lasts as long as it is maintained, and the maintenance is cheap compared to replacement as long as you never let it lapse.
If you are trying to work out whether an existing system has years left or is quietly costing you more than a replacement would, describe what you have — you will get an honest read, including the version where you keep what you have. If you are at the other end and specifying something new, how a build runs here covers the handover and ownership terms that decide the lifespan, and the estimator gives a price indication in a few minutes.