The case for boring technology in client web projects

It's tempting to build every client project on whatever's newest: the framework with the best developer experience, the freshest tooling. The client, however, isn't hiring a framework; they're hiring a system someone else will eventually need to maintain, debug, or hand off to a different developer.

"Boring" technology (a framework with a multi-year track record, wide hiring pool, and mature documentation) trades a little developer excitement for something more valuable to the client: the next person who touches this codebase, in two years, won't need to relearn a tool that's since been abandoned or rewritten from scratch.

This isn't an argument against ever adopting something new. It's an argument for asking who bears the risk of that choice: if it's the client's long-term maintainability, the decision should weigh that risk seriously, not just the fun of building with something new.

The best compliment a client web project can earn isn't "impressively cutting-edge." It's "still easy to work on, three developers and two years later." That compliment is earned by boring choices made deliberately, not by accident.