Most of the web is built to expire
There is an unspoken assumption in a lot of web work: that the site is temporary. It will be rebuilt in two or three years, so why engineer it to last longer? That assumption is usually self-fulfilling. Build something fragile and dependent on whatever framework is fashionable this quarter, and in two years it will indeed be unmaintainable - not because the web moved on, but because you built it to.
We reject the premise. The web platform itself is remarkably durable. HTML written in 2005 still renders. The standards do not break your old pages - your dependencies do. So the question is not whether durable web work is possible. It is whether you are willing to make the choices that produce it, most of which are quieter and less exciting than the alternatives.
Semantic HTML is the bedrock
Permanence starts with the layer that almost never changes. The semantics of HTML - a heading is a heading, a button is a button, a list is a list - have been stable for a very long time and will outlive every framework currently in fashion. A site built on correct, semantic markup has a foundation that does not rot.
This is not nostalgia. Semantic HTML is what makes a site accessible to screen readers, legible to search engines, and resilient when the JavaScript fails to load. When you use a real button element instead of a styled div, you inherit keyboard support, focus handling, and assistive-technology behaviour for free - behaviour that does not break when your component library is deprecated, because it was never yours to break. The most future-proof code is frequently the code you did not write because the platform already had it.
Progressive enhancement: start with what cannot fail
The core idea of progressive enhancement is to build in layers, starting with the most robust and adding the more fragile on top. The content and core functionality work with nothing but HTML. CSS makes it beautiful. JavaScript makes it richer. If a layer fails - a script errors, a connection drops, an old browser chokes - the layers beneath it still stand, and the user still gets what they came for.
This is the opposite of the common approach, where nothing works until a large bundle of JavaScript has downloaded, parsed, and executed successfully. That approach treats the most fragile layer as load-bearing. Progressive enhancement treats it as a bonus. The result is a site that degrades gracefully instead of failing completely - which, over a five-year horizon spanning browsers and devices you cannot predict, is the difference between a site that lasts and one that quietly stops working for a slice of its audience.
Choosing technology that ages well
Not every dependency is a liability, but every dependency is a bet on someone else's future. So we choose them conservatively. We favour tools that are close to the platform over tools that abstract far away from it, because abstractions are where the fragility accumulates. We prefer libraries with a long track record and a healthy community over whatever launched last month with the most enthusiastic announcement. We keep the dependency tree shallow, because every package is a maintenance burden and a potential point of failure for as long as the site lives.
This is the through-line of our engineering practice: the goal is not to use the newest thing. It is to use the thing that will still be a defensible choice in five years - and to write our own code clearly enough that a future engineer, possibly one of us, can understand it without an archaeology dig.
Permanence is a kind of respect
Building for permanence costs a little more up front. It means resisting the shiny option, writing the boring abstraction, and testing the path where things fail. The payoff is a site that does not need to be thrown away and rebuilt every couple of years - that keeps serving the brand, and keeps returning on its investment, long after launch.
That durability is, in the end, a form of respect: for the client's money, for the user's device, and for whoever has to maintain the thing next. If you would rather build once and build well than rebuild on a schedule, let's talk.