The Case for Boring Technology

Dan McKinley wrote "Choose Boring Technology" back in 2015, and the essay has aged better than almost any codebase from that year. His frame was that every team gets a limited number of innovation tokens, and you should spend them on the thing that makes your product different, not on the database.

Eleven years later I run a small studio that ships client sites weekly, and I want to make the working-practitioner version of that argument, because the pressure to spend tokens you do not have is worse than ever. Every week there is a new runtime, a new framework that renders things in a newer place, a new database that promises to be all the old databases at once. Some of it is genuinely good. Almost none of it belongs in a client project.

What boring actually means

Boring does not mean old, and it definitely does not mean bad. Boring means the failure modes are known.

Postgres is boring. When Postgres does something strange at 2am, the answer is on the first page of results, written in 2019, with three confirmations and a workaround. A database that launched eighteen months ago can be faster, nicer, and better designed, and still lose to that. The unknown failure mode you hit in month six costs more than every convenience the new tool bought you in months one through five.

By this definition, some new-ish things are already boring. Next.js is boring now; I wrote about why we reach for it and the reasons are all dull ones: hiring, documentation, a decade of Stack Overflow answers, hosting that just works. Tailwind is boring. SQLite is gloriously boring. Boring is a maturity state, not an age.

The client-work multiplier

Everything McKinley said about innovation tokens gets multiplied when you build for other people.

A product team that adopts an exotic stack at least stays in the building with it. The people who chose it maintain it, learn its sharp edges, and absorb the cost of their own enthusiasm. An agency does not get that loop. We hand the project over. Someone else's future developer, someone we will never meet, inherits the stack choice. Choosing an exotic tool for a client project is spending someone else's innovation tokens without asking.

There is a shabbier version of this that I want to name, because clients should watch for it: agencies picking the new thing so their developers stay entertained, or so the case study looks impressive at a conference. Resume-driven development is real, it is common, and the client pays for it twice: once in bugs during the build, and again in two years when nobody can find a developer who knows the framework that was hot for one summer.

Our rule is simple. The stack we sell is the stack we would want to inherit.

Where the shiny thing earns it

This is not a sermon against ever adopting anything, because that fails too. Teams that never spend an innovation token end up maintaining a PHP 5 monolith with a jQuery frontend and calling it discipline. Stagnation has failure modes just like novelty does; they are just slower.

So here is the test we actually use before letting something new into a client build:

• It has to remove a whole category of work, not shave ten percent off one. Static generation removed servers to babysit for most brochure sites; that earned it. See static sites are back for how that one played out.
• It has to fail loudly and early, not quietly and late. TypeScript passed this test years ago. A clever new data-fetching library that silently caches the wrong thing does not.
• We have to have used it on our own stuff first. Our site, our internal tools, our experiments. We spend our own tokens before we spend a client's. That is where our AI tooling went first too, and it changed how we build, but the point is the sequencing: playground first, production later, client production last.
• Two of us have to be able to maintain it. If only one person in the studio understands the choice, it is not a stack decision, it is a bus-factor problem with good branding.

Most things fail the test. That is the test working.

What this buys you

The unglamorous payoff is that boring stacks make estimates honest. When the tools are known, the risk lives in the actual problem: your catalog structure, your booking flow, your content. That is risk we can see and price. When the tools are novel, the risk hides in the plumbing, and it surfaces as the week-three surprise that blows the timeline. Nearly every project horror story a client has told me traces back to plumbing risk someone chose voluntarily.

Speed, too. Not build speed, life speed. A boring stack means the fix for next year's bug is a search away, the developer who patches it in 2029 exists, and the hosting bill stays legible. What makes software feel fast is mostly restraint, and restraint starts at the stack.

If you are hiring anyone to build for you, ask them one question: who maintains this in three years, and what will that person find? The answer tells you more than the portfolio. Ours is on the technologies page, and if you want to talk through a build where the interesting part is your business and not our toolchain, book a call. Boring on purpose is still the most underrated feature we ship.