what makes a product last

A few weeks ago, I bought a photograph of Omega Centauri on eBay.

It is one metre by one metre and shows a cluster of around ten million stars, shot from the Atacama Desert. From across my bedroom, it looks like a cloud of white dust. Up close, every speck turns out to be a star.

Omega Centauri is around 17,000 light-years away from Earth. The light captured in that photograph started travelling towards us 17,000 years ago. What hangs on my wall is how Omega Centauri looked back then.

The picture makes me think differently about time.

At work, I am leading a project to build a new generation of software for care organisations across Europe. Over time, it will replace several legacy systems that have been around for decades. Some still run on servers in the basements of care organisations. The oldest dates back almost fifty years.

Together, these products are used by hundreds of thousands of social care workers across Europe. If we do our job well, many of them will spend a large part of their working day using the tools we are building now, perhaps for decades.

What does it take for a product to last that long?

what stays the same

At first, I thought replacing legacy products was mostly a matter of making good decisions early: choose the right technology, design a robust architecture, and establish a modern design system.

Those decisions are important. But a good decision today can still become a bad one twenty years from now. The systems we are replacing are probably full of choices that were perfectly sensible when they were made.

Their age is visible. The interfaces look like Excel from another era. Some loading screens last long enough to make a coffee. And many workflows feel unnecessarily complex now that you can simply tell your beloved LLM what outcome you want.

When we decided what to carry forward, we realised that very little of the software itself should survive. Interfaces and infrastructure need to change, the code cannot be reused, and many features will disappear as we build around the possibilities of AI.

If almost everything changes, what makes it the same product?

The basic principles underneath the software remain the same. Fifty years later, there are still people receiving care. Their care still needs to be planned and documented. Employees still work shifts. Care organisations still need to invoice and get reimbursed.

But I think the most valuable thing to carry forward is what has been learned while building these products.

One of the product owners on the new project has spent many years working on one of the legacy systems. He knows where its complexity came from and why decisions that look strange today were made.

We paired him with a second product owner without years of experience in care software. She thinks more about simple, modern UX, rapid prototyping and AI.

He can explain why something was needed. She can challenge whether it still needs to.

how products get old

Products get heavier over time.

One customer asks for something. A few weeks later, another needs a slightly different version. So a setting gets added to support both, because changing the old behaviour would break the first customer’s workflow.

Ten years later, the product is carrying hundreds of decisions like that. Eventually you hear:

We can’t touch that. Nobody knows what else it might break.

I think that is when a product starts getting old. Not when it looks old, but when changing it becomes dangerous.

A star like the Sun can look almost unchanged for billions of years while hydrogen slowly turns into helium inside it. From the outside, very little seems to happen. Underneath, it is changing the entire time.

I used to think of a product as having one lifecycle: it launches, grows, matures and eventually declines. Now I think a product that lasts for decades needs many smaller lifecycles inside it. Features, interfaces, technologies and architectures need to be able to end without taking the whole product with them.

The product survives because its parts do not have to.

That changes what building for the long term means to me. Sometimes the right thing is not to add something new, but to remove a feature, redesign a component or replace a technology before it’s too late.

Anything that exists long enough will become legacy. The goal is to make it replaceable before it does.

If you looked at Omega Centauri again a million years from now, it would still be Omega Centauri. But the stars inside it would all be a little further along in their lifecycle.

I hope the same is true for what we are building now.

If care organisations are still using something that grew out of what we are building today in thirty years, ideally someone has replaced the technology we chose with something better, proved some of our assumptions wrong and removed features we currently think are important.

What remains might be the understanding of the work and the reason we built it in the first place: giving people more time to care for other people.

I think that is what makes a product last. Not that everything inside it stays the same, but that it keeps changing without losing what it is for.