22 years of building: what actually lasts
We have been building digital products since 2003. Some of them are still running. Some are not. Here is what we have learned about the difference.
Yonescat has been building digital products since 2003. That is long enough to have shipped things that are still running twenty years later, and things that did not survive their first year. It is long enough to have watched the industry cycle through Ajax, Web 2.0, mobile-first, flat design, material design, microservices, the blockchain moment, and now AI. Some of those waves were real. Some were noise.
Here is what we have learned about what lasts.
The technology is rarely the constraint
When the Circulation Foundation asked us to rebuild their patient-facing website for NHS vascular patients, the hard problem was not the CMS or the framework. It was understanding how a person experiencing vascular symptoms would navigate information under stress — and what the NHS design guidelines required in that context. Getting that right required time with clinicians and with patients. It required content decisions, not technical ones.
That website still receives 60–80 thousand visits a month. Not because of the stack we chose. Because the information architecture was right.
When we built the Log Cabin's mobile app — a service for children and young people with disabilities in Ealing — the technical implementation was straightforward. What was not straightforward was designing a notification system that worked for parents, carers, volunteers, and the young people themselves, each with different needs and different relationships to the service. The app entered daily use from launch. It still runs. The complexity we solved was human, not technical.
What does not last
Bespoke systems with no knowledge transfer. We have seen organisations return to us years after a project with a system they cannot maintain, because the agency that built it documented nothing, trained nobody, and moved on after invoice. The system decays. The organisation has lost the investment.
Projects without a clear owner. The sites that go stale are almost always the ones where nobody internally was accountable for them after launch. Not because they were built badly, but because there was no one to respond to the world changing around them.
Technology chosen for the demo. We have worked on rebuilds of systems built on impressive-sounding stacks that were chosen because they looked good in a proposal. The underlying problems — a data model that did not match the domain, a content structure that did not reflect how users actually searched — survived the shiny technology and outlived it.
What does last
Ownership. The organisations whose digital systems hold up over time are the ones where someone inside the organisation deeply understands what they have. We build for knowledge transfer. When we handed over the RAS website, the team could run it. When we trained the St Michael's Fellowship staff on their Drupal CMS, they could update content without calling us.
Honest scoping. The projects that run into trouble are almost always the ones that were scoped to win the business rather than to solve the problem. We have turned down work where we thought the scope was wrong. That is not altruism — it is self-interest. A project that fails damages everyone.
Relationships over transactions. Most of our clients have been with us for years. Some for over a decade. That continuity means we understand their systems, their constraints, and their goals in a way that a new supplier cannot. It also means we tell them things they do not always want to hear, because the relationship can carry that.
What we have changed our minds about
We used to believe that good process produces good outcomes reliably. It does not. Process reduces the variance, but the work still requires judgment that process cannot encode. The judgment comes from experience — from having seen what breaks and what holds, across enough different contexts that patterns emerge.
Twenty-two years gives you a lot of patterns.
The one that matters most: software that serves people with real needs, built by people who understand those needs, lasts longer than software built to a specification. The specification is always incomplete. The understanding is not.