The technologies in this series didn't survive forty years by accident. Someone, at the start, made choices that let them keep running — and someone every year since refused to break them. Longevity is not luck. It is a decision you make on purpose, repeatedly.
We've spent four posts on why old tech keeps winning: the idea outlives the packaging, a modern lens distributes it, delivery keeps it relevant, and old primitives let it scale. This last post is about the quality underneath all of it — the one that turns a clever build into a durable one. Longevity. And in this field, longevity is observed, measured and engineered.
The Lindy effect: age is information
For things that don't wear out — ideas, protocols, formats — every year survived is evidence of more years to come. A technology that has worked for forty years is a safer bet than one that launched last quarter, precisely because it is old. That is the Lindy effect, and it is the most underused signal in technology selection.
Four choices that buy you a decade
When we build something we intend to outlast the trend cycle, these are the decisions that do the work. None are exciting. All of them compound.
1. Never break the contract
The reason old systems endure is a fanatical commitment to backward compatibility. The interface from a decade ago still works. You add, you deprecate slowly, you almost never remove. Every breaking change is a small act of telling your past users they don't matter — and durable software refuses to send that message.
// longevity is additive, not destructive
// v1 still works in v3 — you extend, you don't replace
function send(opts: { to: string; subject: string;
// added in v2, optional so v1 callers are untouched
replyTo?: string;
// added in v3, same rule
tags?: string[];
}) { /* ... */ }2. Choose boring on purpose
Boring technology has a known failure surface. You know how it breaks, who has hit the bug before you, and what the fix is. Exciting technology hides its failure modes until you find them in production at 2 a.m. We spend our novelty budget on the product, never on the foundation.
3. Separate the durable core from the disposable shell
The longest-lived systems keep their business logic — the rules that are actually theirs — clean and independent of whatever framework is currently in fashion. Frameworks are shells; they get replaced. The core should not have to notice. Decoupling the two is the single most important longevity move in the whole stack.
4. Write it for the person who maintains it
Code is read far more than it is written, and maintained far longer than it is built. The studio that names things clearly, deletes dead code, and writes the comment explaining why is buying years of future velocity. Longevity is mostly a gift you leave for whoever opens the file next — often yourself.
Longevity as a business strategy
This is not only an engineering value — it is how a small studio compounds. Software that lasts is software you build once and keep selling. Every system that keeps running is a system you are not rebuilding, which means your effort accumulates instead of resetting. A studio that ships durable things gets quietly, relentlessly more capable every year.
Build things that are still running when everyone has forgotten you built them. That is the whole game.
— Jordan Morris
Where the series lands
Old tech keeps coming back because the ideas were always sound; we just give them a modern lens, distribute them, deliver them well, scale them with proven primitives — and build them to last. None of that is nostalgia. It is the most practical way we know to build software that is still earning its keep long after the launch.
- Part 1 — Old code never dies: the idea outlives the packaging.
- Part 2 — The modern lens: distribute single-machine tech across the cloud.
- Part 3 — Delivery is the feature: modern delivery keeps old ideas relevant.
- Part 4 — Scaling inside the code: the old primitives that scale.
- Part 5 — this post: longevity, engineered on purpose.
We build systems designed to still be running in five years — durable cores, boring foundations, modern lenses. If that is the kind of software you want, let's talk.
Start a projectQuestions, answered
- Doesn't 'build to last' slow you down versus shipping fast?
- Only up front, and only a little. The choices that buy longevity — backward compatibility, boring foundations, a decoupled core — are cheap when made early and ruinous to retrofit later. Speed and durability conflict far less than the rewrite they prevent.
- How do you decide what's worth making durable?
- The core business logic — the rules that are genuinely yours — always. The shell around it (frameworks, UI, delivery) can be disposable and modern, because it's expected to be replaced. Durable core, fashionable edge.
The stack we actually use
The tools below run our own systems and the ones we build for clients. A few are affiliate links — they support The Signal at no cost to you.
Some links on this site are affiliate links. If you click through and sign up or buy, J Supreme Tech may earn a commission at no extra cost to you. We only recommend tools we actually use to build and run our own systems. Full disclosure.