Boring Technology, Deliberately: Choosing Tools You Can Still Hire For

A team picked a message queue nobody on it had run in production, because the benchmark was better and the documentation looked tidy. Eighteen months later the engineer who chose it had moved on. The two who remained could read the configuration but had never watched it fail. An outage that should have cost forty minutes cost most of a day, and the answer turned out to be sitting in a GitHub issue with four comments, none of them from a maintainer.

Nothing in that story is incompetence. It is an ordinary technology choice that spent more than the team could afford, and the bill arrived eighteen months late, which is how this bill always arrives. So here is the position this piece defends: novelty is a budget, not a virtue. You get a small amount of it per team. Spending it is sometimes exactly right. Spending it by accident, in four places at once, is how a system becomes unmaintainable while every individual decision still looks defensible.

The rule at the end of all this is short: spend the novelty where it is the product, and buy boring everywhere else. Getting to that rule honestly means being precise about what novelty costs, because "boring is better" is a slogan, and slogans lose arguments to benchmarks.

Novelty is a budget, not a virtue

A team can hold a finite number of unfamiliar things at once. Not because engineers are limited, but because operating something means carrying a working model of how it breaks, and that model is built by being paged rather than by reading. Add one unfamiliar component and the team learns it inside a quarter. Add four and nobody ends up holding a model of the whole, which is a different and much worse condition than not knowing one part.

The budget belongs to the team, not the project. It refills slowly, it drains whenever someone leaves, and it is spent by things that never appear on an architecture diagram: an unusual build tool, a hosting provider with its own vocabulary, a deployment model where "region" means something slightly different.

What actually counts as novel

Novelty is relative to your team, not to the industry. A database released fifteen years ago is novel if nobody here has run one in anger. A framework the whole team writes daily is boring even if it shipped last year. The only test that matters is whether somebody in the room has already been woken up by this thing.

Roughly in descending order of what they cost, these are the choices that spend the budget:

• A datastore with an unfamiliar failure model. This is the most expensive line item there is, because data problems are the ones you cannot roll back by redeploying.
• A language nobody writes daily. Not a language nobody knows. A language nobody reaches for at 5pm on a Thursday, which means every change is slower and every review is shallower.
• A deployment target with different semantics. Cold starts, execution limits, filesystem assumptions and networking rules are where the surprises live, and they surprise you in production rather than in staging.
• An architecture the team has read about. Event sourcing, actor models and multi-tenant sharding are all fine. They are not fine as the thing you learn while also shipping the first version.
• A dependency with one maintainer. A single author writing excellent software is a gift and a risk in the same package. The question is what you do the week they stop.

Hiring is the first invoice

The market for a technology is two-sided, and teams usually think about only one side of it. You will eventually need to hire someone who can work in this stack. You will also, eventually, need the people already inside the team to stay interested in a stack that is now on their CV. Both directions get harder as the choices get rarer.

The important part is not any single choice. It is the intersection. An uncommon language is a manageable room to hire from. An uncommon language plus an uncommon datastore plus an uncommon deployment model is a room with about four people in it, two of whom are not looking, and one of whom wrote the library.

That shows up in ordinary situations long before it shows up in recruitment. Somebody goes on leave and there is nobody to cover. A contractor arrives for a fixed piece of work and spends the first fortnight reading. A handover happens and the receiving team quietly rewrites the part they cannot reason about. All of that is the standing cost of what you built, paid monthly in salaries whether or not anyone puts it in a spreadsheet.

Boring choices make ongoing maintenance cheap and predictable, and predictable maintenance is what buys back the time to build anything interesting at all. Teams that spend the whole budget on plumbing have nothing left when the genuinely hard problem arrives.

Documentation depth is a property of the tool

Official documentation is the first layer, and it is usually fine. It describes the happy path, written by people who know the answer, for a reader who has not yet deviated from the intended use. Almost nobody chooses badly because the official docs were poor. They choose badly because the second layer was thin.

The second layer is everything nobody was paid to write: the answered question from 2022 that names your exact error string, the post by somebody who ran this at a scale you are about to reach, the closed issue whose final comment says "turns out it was the connection limit". It only accumulates with time and adoption. A vendor cannot manufacture it.

The error-message test

Before committing to anything, take a plausible error from the tool and search for it. Three outcomes. If a dozen discussions come back, you are buying into a well-worn path. If two come back, expect to be slow. If the only match is the line of source code that raises it, then congratulations: you are now the documentation, and every future engineer on this system depends on notes you have not written yet.

This test has become more important, not less, since engineers started asking assistants instead of search engines. An AI assistant is a compression of that same second layer. Where the layer is deep, the answers are good. Where it is thin, the answers are confident and wrong, which costs more than no answer at all, because a wrong answer gets committed. Choosing an obscure tool today also means choosing to debug without the assistance everyone else on the team quietly relies on.

You debug what you recognise

Operational expertise is mostly a private library of failure modes. Connection pools that exhaust under retry storms. Caches that stampede when everything expires together. Queues that look healthy right up to the moment the consumer falls behind and the lag graph goes vertical. None of that is clever. It is recognition, and recognition is the difference between an incident that lasts twenty minutes and one that eats a working day.

Mature tools do not fail less often. That is the part of this argument people usually overstate. They fail legibly: the failure has a name, the name is written down, and the fix is a search away. A newer tool may genuinely fail less and still cost more per failure, because each incident becomes original research conducted under pressure.

The same recognition gap explains why systems behave differently once real people touch them. Synthetic tests exercise the paths you thought of; the interesting failures come from the ones you did not, which is the whole reason a site can be fast in the lab and slow for real users. Familiar components shorten that gap, because somebody else has already met the pathological case and published what it was.

Who else is watching the tool

There is a security dimension to adoption that gets discussed far less than performance. Widely used software has people looking at it: advisories get filed, scanners recognise its package names, and the fix usually exists before you learn there was a problem. Obscure software has none of that. Nobody files an advisory for a dependency with two hundred users, so your first notification is the incident itself. If you are securing something you did not build, the first thing worth checking is whether every dependency is even the kind of thing a scanner can recognise.

What the difference looks like in year two

In week one the two columns look identical, and the novel option often looks better. These are the differences that surface once the person who made the decision is no longer in the building.

Read the last row carefully, because it turns this into an ethics question rather than a taste question. Whoever picks the exotic option is rarely the person who carries it. That asymmetry is why "I find it more interesting" is not a sufficient argument, and why it deserves saying out loud rather than dressing up as a benchmark.

Where to spend the novelty budget

None of this is an argument for never choosing anything new. It is an argument for choosing deliberately, in one place, for a reason you can write on a single line. Here is the order we would apply.

1. Spend it on the thing customers pay for. If the unusual choice is the reason the product can exist, that is the correct place and possibly the only one. Everything adjacent to it should then be as ordinary as you can stand.
2. Name the requirement the boring option fails. One sentence, written down, circulated. Not "it scales better" but "the familiar option cannot do X, and we need X by March". If you cannot write that sentence, you are shopping rather than choosing.
3. Spend it at the edges before the core. A novel image pipeline can be ripped out in a fortnight. A novel primary datastore cannot be ripped out at all, and everything built on top of it inherits the decision.
4. Spend it once per project, not once per layer. Each new thing is fine alone. The cost is combinatorial, because incidents cross layers and whoever is debugging has to hold all of them at once.
5. Prefer the choice you can reverse. Ask what undoing this looks like in a year, with twice the data. If the honest answer is a migration project, you are not making a technology choice, you are making a commitment.

For everything that is not your product, choose the option with the largest number of people who have already made your mistake.

Rule three pays off fastest, because the safest additions are the ones that produce artefacts your existing pipeline already understands. A content workspace like Acrosite works that way: it generates the required files, commits them to GitHub and triggers the deployment you already run, so the capability is new while the thing you have to operate at 3am is not. Compare that with adopting a hosted system that becomes a runtime dependency of every page render. Same feature on the brochure, completely different risk.

This is also where the build or buy question meets the novelty budget, because buying sometimes spends less of it than building and sometimes spends considerably more. And it is why the rendering decision deserves a deliberate answer rather than a default: whether a site should be static, server-rendered or client-side is really a question about how many moving parts exist at request time, which is another way of asking how much can be unfamiliar when something breaks.

What boring does not mean

Boring is not a synonym for old, and it is certainly not a synonym for popular. The worst position to be in is a tool with a large historic user base and no current maintenance: plenty of tutorials, all describing a version with an open vulnerability, and no upgrade path because the project stopped. That combination is more dangerous than an obscure tool with an active author, and popularity alone will never warn you about it.

The honest concession is larger than that, though. A team that only ever picks the safe option ends up with a system that is easy to operate and hard to staff, because good engineers do want to work on something built after they graduated. Some novelty is genuinely a hiring asset. There is also a version of this argument that becomes an excuse for never revisiting anything, and a stack nobody has touched in six years is not stable, it is unexamined. Deliberate boring means periodically re-earning the choice, which is ordinary product improvement work rather than a rewrite.

The whole argument also inverts in one case: when the unfamiliar tool is the only one that does the job, and the familiar option needs so much custom work that you end up maintaining a worse copy of what you refused to adopt. That happens more often than purists admit. When it does, spend the budget without apology and make every other decision on the project deliberately dull. Our parent company has written about the layer sitting above all of this in what a company actually sells, and the connection is direct: the parts nobody is buying should not be the parts you are proudest of.

How we would decide on Monday

Start with an inventory rather than a debate. List every technology down one side of a page. On the other, put the number of people who could operate it alone and the date somebody last upgraded it. Two patterns matter: a component with a single name beside it, and a component with a date three years old. The first is a staffing risk, the second a security one, and both stay invisible in planning because neither has caused an outage yet.

Then apply one filter to anything new that wants in. If this component vanished from the internet tomorrow, what breaks and how long does replacing it take? Answers measured in days are cheap novelty, and you can be relaxed about them. Answers measured in quarters need the requirement written down first, and probably need a second person to put their name to it.

The last thing worth saying is that the interesting engineering is almost never in the stack. It is in the modelling, the edge cases, the thing that makes this product different from the one beside it. A deliberately dull foundation is what leaves room for that, and it is the shape we default to when we take on web application work. If you are weighing a specific choice and want a second read on it, tell us what you are considering and what it would replace.