Clients sometimes expect the newest framework. They have read a launch post, watched a conference talk, or heard from a friend’s nephew that everybody serious has moved on to something released eight months ago. I usually recommend the boring one. Not because I dislike new things, and not because I am too lazy to learn them, but because I have watched what happens to projects two, three and five years after launch, long after the excitement wears off and the only question left is whether the thing still works.
Boring tools have answers on page one of every search. When something breaks at 11 p.m. on a Friday, that fact matters more than any benchmark. This post is my attempt to explain, as plainly as I can, why I choose tools that are ten years old, and why I think that choice is one of the most valuable things I offer the people who hire me.
What I mean by boring
Boring does not mean bad, and it does not mean old for the sake of old. A boring tool, in my vocabulary, has a few specific qualities. It has been used in production by thousands of teams for years. Its documentation covers the strange edge cases, not just the happy path. Its maintainers have a track record of careful releases and long support windows. And when you describe a problem in a search box, you find a dozen people who hit the same wall and wrote down how they got past it.
For most of the web projects I build, that means a mainstream relational database, a server language that has been around for well over a decade, plain HTML and CSS with a light layer of JavaScript, and a hosting setup any competent developer could understand in an afternoon. When a project truly needs something more specialized, I reach for it. But that is the exception I have to argue myself into, not the default.
Fewer surprises
Mature tools have their bugs found and fixed already. That sentence sounds obvious, but its consequences are enormous. A framework that is a year old has been tested by its early adopters. A framework that is ten years old has been tested by everyone: the giant retailers, the tiny nonprofits, the student projects, the government portals, the weird plugins nobody should have written. Every sharp corner has been bumped into by somebody, and most of them have been sanded down.
I learned this lesson on a project for a small furniture maker in Asheville, North Carolina, early in my career. I chose an exciting new front-end library because it promised a smoother shopping cart. It did deliver that, for about four months. Then the library’s authors released a major version that changed how state worked, the plugin I relied on for image galleries was abandoned, and a security notice went out for a dependency three layers deep. I spent the next six weeks of unpaid evenings migrating a site that had been working perfectly well. The client never knew how close their checkout came to breaking. I knew.
Innovate in the product, not the plumbing.
Leo
That project is where this phrase came from. Clients do not pay me so they can own an interesting dependency tree. They pay me for a product that helps their customers. Every hour I spend wrestling an immature tool is an hour I am not spending on the parts of the project that actually make it different: the onboarding flow, the search that understands their catalog, the page that loads instantly on a cheap phone.
Easier hiring
The next developer will know them too. This is the argument clients find most persuasive once I explain it, because it is about their future, not mine. I will not be on every project forever. Someday a client will hire someone else to add a feature, fix a bug or take over entirely. If I built their site with a mainstream stack, they can post a job and get dozens of qualified replies. If I built it with something niche, they may get three replies, all expensive, and one of them will suggest rewriting everything.
I once inherited a project from a developer who had built a membership site for a regional hiking club using a framework that, by the time I arrived, had fewer than a hundred people still discussing it online. The club’s treasurer, a retired engineer named Gloria Fenn, told me they had spent nearly $6,000 over two years just keeping it running. We moved it to a boring, well-supported stack in about five weeks. Her first email afterward was a single line asking why nobody had done that sooner.
When I do choose something new
I am not a purist about this. There are times when a newer tool is the right call, and I try to be honest with myself about when those times arrive. My rough test looks like this:
- Does it solve a problem the boring tool cannot? Not “solves it more elegantly.” Actually cannot, or only with heroic effort.
- Is the problem central to the product? A new tool for the core feature might be worth the risk. A new tool for the contact form almost never is.
- Can I contain it? If the new piece sits behind a clear boundary, it can be replaced later without tearing up the whole project.
- Will the client understand the tradeoff? I explain the risk in plain language and let them decide, in writing.
Most ideas fail at step one. A few make it all the way through. On a recent real-time dashboard for a delivery company, for example, a newer streaming approach was genuinely the right answer, and I used it, carefully fenced off from the rest of an otherwise very ordinary application.
The quiet benefits
There are smaller advantages that rarely make it into the debate. Boring tools tend to have stable hosting options at reasonable prices. They work with the monitoring and backup services clients already pay for. Their security patches arrive on predictable schedules. Their documentation has been translated, rewritten and improved by years of contributors. And because so many people use them, the community has already built the boring-but-essential extras: form validation, image handling, logging, accessibility helpers.
There is also a personal benefit. When I use well-understood tools, I spend my creative energy on the interesting parts of a project, and I sleep better. I am not checking release notes at midnight wondering which part of my stack changed under me. That calm shows up in the work.
Key takeaway: choosing a mature tool is not a lack of ambition. It is a deliberate decision to spend your ambition where your users will feel it.
Boring on purpose
If you are a client reading this, here is my honest advice: when a developer pitches you the newest thing, ask them three questions. How long has it been around? Who else is using it in production? And who will maintain it if you stop working together? Good developers will have clear answers, and sometimes those answers will be convincing.
If you are a developer, try an experiment on your next project. Pick the most boring option for every layer, then write down every moment where it held you back. In my experience the list is short, and every item on it is a real, specific reason to reach for something newer. Everything else is just plumbing, and plumbing should be the least interesting thing in the building.
Sharing this with my friends.
Saved this one for later. Really useful.