New frameworks appear every week. New languages get hyped every month. Right now, in early 2026, everything has to involve AI in some way or another. It is tempting to chase the latest trend. But I have found that the most reliable way to deliver value is to use technology that has been around long enough to be considered boring.

The appeal of the new and shiny

I understand the attraction. A new framework promises to solve all the problems the previous one had. A new database promises to handle scale in ways the old one never could. A new paradigm promises to change how we think about everything. It is exciting. It feels like progress.

The problem is that new technology comes with unknown failure modes. You will be the one discovering them. At three in the morning. On a Saturday. When your customers are waiting.

Boring is predictable

A relational database like PostgreSQL has been around since the mid-1990s. It is well understood. When something goes wrong, someone has seen it before. There are answers on mailing lists, in documentation, and in the collective experience of thousands of developers who have used it in production for decades.

That predictability is valuable. It means you can spend your time solving your customers' actual problems instead of fighting your infrastructure. It means that when something breaks, you have a reasonable chance of understanding why.

Startups and laundromats

There is a striking contrast in the business world that I think applies here. About 90% of startups fail. The number varies depending on who you ask and how you measure, but the order of magnitude is consistent. For venture-funded startups, some estimates put the failure rate even higher.

Laundromats, on the other hand, are often cited with a success rate around 95% over the first five years. That number should be taken with some scepticism. It appears to originate from loan performance data rather than a rigorous study, and struggling laundromats tend to change owners rather than close, which makes the statistic look better than reality. But even with that caveat, the contrast is real.

Why? A laundromat solves a problem that everyone has. People need clean clothes. The demand is predictable and constant. There is no need to convince anyone that they need the service. A startup, on the other hand, often has to create its own market. The most common reason startups fail is that there is no market need for what they are building.

I have seen this before

During the dot-com boom, I worked at a startup called Goyada. I joined in 2000 and left in 2002, though I went back a few times over the years to do some contracting. We had lots of ideas. High-flying ideas about what the internet could become. I listened to them and I could not understand which one of them would actually make us money.

The technology choices reflected this. Some parts of the system used object oriented databases. They were exciting at the time. They never took off. We also looked at IBM DB2 and I think we used it for a short while until someone realised that it was really expensive and did not bring much value over the alternatives.

Except one idea. Goyada sold prepaid codes for mobile phones in Sweden. Buy a code at a lower price than you sell it for. That was a business model I could understand. It was not glamorous. It was not going to change the world. But it was a transaction that made sense. Someone wanted a prepaid code, we had one, and the margin was positive. The prepaid business used MySQL. It was fairly new and shiny back then. Not so much today.

That mundane, understandable idea turned out to be the one that actually survived. Goyada kept going for about 20 years before it finally went bankrupt in January 2020. All the high-flying ideas from the dot-com era were long gone by then. The object oriented databases were long gone. The boring idea, backed by a boring relational database, outlasted them all.

Solving actual problems

This connects directly to technology choices. When you pick a boring, well-understood technology, you are doing the same thing as the laundromat owner. Or the prepaid code reseller. You are choosing something with known demand and predictable behaviour. You are not betting on the market accepting something new. You are building on a foundation that works.

Right now, it seems like every new product has to be an AI product to attract attention and funding. That may work for some. But for most, I suspect it is the equivalent of opening a startup when you could be opening a laundromat. The excitement of venture capital feels good until the investors start expecting a return. Solving a real, mundane problem that people actually have tends to be a more sustainable path.

When to pick boring

I am not saying you should never use new technology. Sometimes a problem genuinely requires something that did not exist five years ago. But that is rarer than we like to admit. Most systems I have worked on would have been perfectly well served by a relational database, a well-structured application in a mature language, and a deployment pipeline that does not require a PhD to understand.

And sometimes the new thing really does change how you work. Coding assistants are an example. They do not replace thinking, but they remove a lot of the tedious parts. Looking up API details, generating boilerplate, exploring unfamiliar codebases. That is a genuine improvement in my daily work, not just a shiny distraction.

The difference is that a coding assistant helps me build with boring technology faster. It does not ask me to replace the boring technology itself. The best new tools tend to work that way. They make the proven foundations more accessible, not less relevant.

The question I try to ask myself is: "Am I choosing this because it solves my problem, or because it is exciting?" If the honest answer is that it is exciting, I take a step back and look for the boring option.

Conclusion

Boring tech is stable. It works. You will not be woken in the middle of the night by angry support staff. That alone makes it worth choosing.

Acknowledgements

I would like to thank Malin Ekholm for feedback.

Resources