Boring tech, brave decisions

The technology choices that drive most successful products are, in retrospect, deeply unfashionable. PostgreSQL. Server-rendered HTML. Background workers. Boring caching layers. Standard authentication. The kind of stack that does not generate Hacker News comments.

This is not because the engineers who chose them did not know about newer options. It is because the people who repeatedly ship reliable products have learned, often painfully, that the cost of novelty is usually higher than the benefit, and the cost is usually paid by the future versions of themselves.

The case against reaching for novelty

Every new technology comes with a hidden tax. Documentation gaps. Sparse community knowledge. Edge cases that have not been hit yet because not enough people have used the technology in production. Integration with the rest of your stack that is not as smooth as the marketing suggests. The first six months with any new technology, in our experience, is a period of paying down its unknowns.

Mature technologies have already had this period paid down by their communities. The edge cases are documented. The integrations are well-trodden. The bugs that ship today were probably documented in a Stack Overflow answer five years ago. The reliability that mature technology offers is not free — somebody paid for it — but it has been paid for already, and you get to benefit from that without writing the cheque yourself.

This is the case for boring tech. Not "old equals good," but "proven equals predictable," and predictability is what lets a small engineering team ship reliably over a long enough timeline.

What "boring" actually means in practice

Boring is not the same as old. PostgreSQL is boring. So is React, despite being more than a decade old. So is HTTP. The defining property of boring tech is not age but maturity — wide adoption, well-documented failure modes, predictable behaviour under stress, and a deep bench of engineers who can debug it.

By this definition, the boring stack for most projects in 2026 includes:

• Postgres for the transactional database
• Redis for caching and lightweight queueing
• S3-compatible object storage for blobs
• HTTP APIs as the primary integration surface
• A standard authentication library for the language being used
• A mainstream cloud provider as the deployment target
• A well-known frontend framework for the user interface
• Server-rendered HTML with progressive enhancement wherever the use case allows

None of these are exciting choices. All of them are predictable. The team that adopts this stack and applies judgement to the small set of decisions above gets a baseline of reliability that is genuinely hard to beat with novel choices.

The places where novelty actually pays off

None of this is an argument that every choice should be boring. The whole point of being disciplined about boring tech in most decisions is that you preserve your budget for novelty in the small set of places where novelty is the differentiator.

Those places are usually:

The thing you are selling

If your product is novel, the technology that delivers that novelty has to be appropriate to it. A company selling cutting-edge AI features cannot use a five-year-old AI stack and expect to compete. The differentiating layer of the product is where novelty pays off, because the alternative is shipping a product that does not actually differentiate.

But notice the scope. The novel layer is usually a small part of the system. The infrastructure underneath it, the boring CRUD around it, the user authentication on top of it — these can all be boring even when the core engine is bleeding edge. The mistake is letting novelty spread from the core into the periphery, where it has no business being.

Performance bottlenecks that the boring stack cannot meet

Occasionally, a specific workload genuinely outgrows boring tech. A real-time feature that needs sub-millisecond latency. A data volume that conventional databases struggle with. A throughput requirement that standard message queues cannot meet. When the boring stack is genuinely the bottleneck — and the team has proven this with measurements, not just assumptions — that is the right time to reach for something more specialised.

The key word is "proven." Many teams reach for novel tech to solve problems they have not actually measured. The reliable practice is to start boring, measure, and switch only when the boring choice is the demonstrable bottleneck.

Capabilities that simply did not exist before

Some categories of technology represent genuinely new capabilities — large language models, real-time multiplayer infrastructure, certain kinds of streaming systems. There is no boring alternative because the capability did not exist five years ago. In these cases, the discipline is to use the new technology carefully, with sober assessment of its production readiness, rather than to avoid it.

The judgement involved

Boring tech is not an algorithm. It is a discipline that requires judgement at every decision point. The question to ask, on each technology choice, is: is the cost of this choice's novelty justified by what it gives me, or am I picking it because it is more interesting to work with?

The second motive is real, common, and difficult to admit. Engineers — including ourselves — are drawn to new technology partly because it is intellectually interesting. The discipline of boring tech is partly about owning that bias and counterweighting it deliberately.

The teams we have seen ship most reliably are the ones who have made peace with this. They use boring tech where they can. They reach for novelty where they must. They are honest with themselves about which case they are in for any particular decision. The result is products that ship faster, run more reliably, and require less heroic intervention to keep alive.

What this looks like in our own work

Our default stack at TrueLeaf Tech reflects this discipline. We use Postgres unless there is a clear reason not to. We use Redis for caching. We deploy on mainstream cloud providers. We use standard frameworks. We reserve novelty for the layers of the product where novelty is the differentiator — currently, almost always the AI features themselves.

This is not exciting. It does not generate conference talks. But it has correlated strongly with the engagements where our clients have shipped products that continued to work well for years after we handed off. That correlation, in our experience, is not a coincidence.

If you are starting a new project this quarter, the most underrated decision you can make is to choose the boring option in eighty percent of the decisions ahead of you. You will free up an enormous amount of attention for the twenty percent where novelty actually matters. And the eighty percent of decisions that you got out of the way quickly will, in three years, be the thing that lets the product still be running.