Every piece of software has a half-life. The moment it’s released, it begins to decay.
Not in the way metal rusts or wood rots, but in relevance, in adaptability, in the gap between what it was designed to do and what the world now requires of it.
At first, it works beautifully. A new system replaces the old one, the team congratulates itself, and for a brief period, the product feels timeless. But slowly, entropy creeps in. Edge cases pile up. The market shifts. Developers leave. Documentation goes stale. The software remains running, but it drifts further and further from the reality it was meant to model.
The decay is invisible—until it isn’t
Unlike a building with cracks in the walls, software looks pristine from the outside. A 20-year-old codebase can serve up a slick modern UI. But under the hood, the abstractions are fraying. APIs that once made sense become convoluted. Features added in a rush break the internal logic. Eventually, every change feels like a hack.
This is why so many organizations underestimate decay. They think: if it still runs, it still works. But function is not the same as health. By the time the cracks are visible, the half-life is already well underway.
Every system becomes legacy
There’s a tendency in startups to believe that legacy systems are what other companies have. That our stack, being new, will never need to be replatformed. But given enough time, every system becomes legacy.
The languages you chose will fall out of favor.
The frameworks will stop being maintained.
The engineers who understood the original design will leave.
The business will evolve in ways the software never anticipated.
It’s not a matter of if but when.
The myth of the “final rebuild”
Leaders often believe they can get ahead of this by doing a massive rewrite or replatforming. The big bang that will “finally” fix everything. But that, too, has a half-life.
Rewrites buy you time, but they don’t solve the underlying truth: software lives in a moving world. Business models change, integrations multiply, user expectations shift. The best you can do is extend the half-life.
Extending the half-life
So what does it mean to design for decay?
Modularity over monoliths – Smaller pieces decay independently; whole systems don’t collapse at once.
Interfaces over internals – APIs last longer than implementations. Stable contracts buy time.
Continuous investment – Treat software like infrastructure, not projects. Paving roads beats rebuilding cities.
Cultural humility – Assume today’s stack will be tomorrow’s legacy. Build with turnover in mind.
The half-life of software is shorter than we want it to be. But acknowledging it changes how we build. The goal isn’t immortality—it’s resilience.