Choosing a tech stack that won't expire

Every few years the industry declares a new way to build websites, and a generation of businesses inherits sites nobody can maintain. The framework was hot; the agency moved on; now a quote to change the phone number reads like a ransom note. Stack choice is a business decision wearing a technical costume.

Fundamentals age like cast iron

Some technologies have survived every hype cycle because they sit close to how the web actually works: HTML, CSS, HTTP, SQL, JavaScript. Nothing built directly on fundamentals ever becomes unmaintainable — at worst it becomes unfashionable, which costs you nothing.

The layer above — frameworks — ages like produce. Some of it keeps remarkably well (React has been a safe bet for a decade; Postgres for three). Some of it was compost in eighteen months. The difference is rarely quality. It is adoption: tools with millions of users and a deep bench of maintainers get boring, and boring is the goal.

Our rules, roughly

• Boring core, adventurous edges. The database, the language, the rendering layer: maximally boring (Postgres, TypeScript, React). Experiments are allowed at the edges, where replacing them later is an afternoon.
• Prefer platforms' losers to startups' winners. A "worse" tool backed by a massive ecosystem outlives a better tool backed by a Series A.
• Every dependency is a hire. It must do a job you cannot do cheaply yourself, and you should be able to fire it. Fewer, heavier-vetted dependencies beat a long tail of conveniences.
• Own your data in an open format. Whatever else changes, your content and customers should live somewhere exportable — SQL, files, Markdown. The stack can expire; the data must not.

The question that filters everything

"If the person who built this disappears, how hard is it to find someone good who can take over?" For React + TypeScript + Postgres, the answer is "an afternoon of interviews." For last year's clever all-in-one platform, the answer might be "rebuild." Ask it about your current site; ask it about any proposal you are handed.

Longevity is a maintenance habit, not a purchase

Even a perfect stack rots if nothing is ever updated. Small, continuous maintenance — dependency bumps, monitoring, the occasional refactor — is what actually keeps a site alive for a decade. That is the honest case for a care plan: not insurance against disaster, but compound interest on the build.

We pick tools we expect to defend in five years. It is a less exciting way to choose technology. It is also why our clients' sites do not expire.