The case for boring technology

There’s a particular kind of meeting where someone suggests rewriting the backend in a language their team has never shipped in production. Everyone nods. No one pushes back. Six months later, the project is late.

I’ve been in those rooms. The technology itself is rarely the problem - it’s the assumption that novelty implies quality. New tools carry hidden costs: unfamiliar failure modes, thinner documentation, smaller communities, and a team that’s learning while shipping.

Boring is a feature, not a flaw

When I choose tools for a project, I’m optimising for the person who has to maintain it in three years. That person might not be me. It might not even be a developer - it might be the client, clicking around a CMS at 9pm because something broke and I’m not picking up.

Boring technology has known failure modes. It has Stack Overflow answers from 2014 that still work. It has upgrade paths. It has a community large enough that someone else has already hit your exact problem and documented the fix.

What this looks like in practice

For most small business websites I build, the stack is Astro, a bit of TypeScript, and as little JavaScript as possible on the client. Not because these are the most exciting tools available - they’re not - but because they’re the right tools for the job and I can build reliable things with them quickly.

Related

• Web Design & Development — how this approach applies to client projects
• Web Design Auckland — working with Auckland small businesses