Every few months some new tech trends:
- A brand new database that will finally replace Postgres
- A language that will finally kill PHP
- A paradigm that makes everything you shipped last year look naive
Four years ago I would read the announcement, get excited, and start rewriting something that was working perfectly fine.
These days I read the announcement, think "cool", and go back to my Postgres, node and .NET. For a while I assumed this was the moment developers stop optimizing for novelty and start optimizing for reliability.
It is not that. Boring is a feature, and as usual it took a few late-afternoon incidents to understand why.
Boring does not mean outdated
Boring technology is technology whose failure modes you already know. Postgres is boring not because it is old, but because when it breaks, it breaks in ways thousands of people have already documented on every imaginable place. Its behavior under load is known. Its sharp edges are mapped. The set of things that can genuinely surprise you is small, and most of the surprises that remain are one search away from someone else's postmortem.
A shiny new database might be better on paper. But every property of it is an unknown to you, and unknowns are not free. You pay for them later, usually at the worst possible time, usually with interest.
The cost of new is paid later, by a tired version of you
In an earlier post I mentioned that the 10PM version of me is always more tired and less patient than the 9AM one. Boring technology is mostly a gift to that person.
When you reach for the exotic tool, you are making a bet that you, or whoever is on call, will still understand it in eighteen months.
That the maintainer will still be around. That the three GitHub issues describing your exact problem will not be the only three that ever existed (and they never was solved). Every one of those bets is fine in isolation. The trouble is that they compound, and the bill always arrives during an incident, never during a calm Tuesday.
Someone once framed this as a budget of innovation tokens: you get a small number, and every novel choice spends one. The mistake I made for years was spending them on infrastructure, the part of the system that is supposed to be invisible, instead of saving them for the part that was actually mine to solve.
Hype optimizes for the demo, not for Tuesday
A lot of technology looks incredible in a fancy conference talk. Five minutes, a clean dataset, a problem shaped exactly to fit the tool. That is the demo.
Then you take it home and run it against real data, real concurrency, real users doing things no one designed for, and a deploy pipeline that has to keep working at 3AM. That is Tuesday. Most hype is tuned for the demo. Boring tech has already survived a few thousand Tuesdays, which is the only review that has ever mattered to me.
This is also why I distrust benchmarks more than I distrust my own taste now. A benchmark is a demo with a chart. The question I actually care about is not "how fast is it when everything goes right", it is "how badly does it hurt when something goes wrong", and nobody puts that on a landing page.
Spend your novelty where it actually matters
None of this is an argument for never trying anything. It is an argument for choosing one place to be interesting and being aggressively dull everywhere else.
When I built Filmle, the only genuinely novel part was the data generation concept: generating a year of daily movie prompts with an LLM and matching guesses with some string-distance math. Everything around it was deliberately boring. A static frontend. No backend. No auth. Hosted on a reliable and safe infrastructure I already understood. The boring scaffolding is exactly what let me pour all of my attention into the one part that was worth the risk.
That is the whole trick. Identify the single hard problem that is the reason your project exists, spend your novelty there, and let the rest of the stack be as unremarkable as possible. A system where everything is exciting is a system where everything can fail in a way you have never seen.
Closing thought
Choosing boring technology is not a sign that you have stopped caring or stopped learning. It is usually the opposite. It means you have been burned enough times to know that the goal was never to look clever in a code review.
The goal is to still understand the system when you are tired, to fail in ways you can predict, and to spend your limited capacity for risk on the one problem that deserves it. Boring is what is left after you remove the parts that were only there to impress someone.
Most of the time, that is the whole system.