Choosing boring technology on purpose

Every technology choice is a loan. Exciting technology borrows heavily: you get capability now and repay in debugging sessions, migration weekends, and abandoned-project graveyards later. My position is that a solo builder should spend novelty in exactly one place — the thing that makes the project distinctive — and choose aggressively boring technology everywhere else.

“Boring” here is a term of praise. It means the failure modes are documented, the answers are on the first page of search results, and the tool will still exist, in recognizable form, in five years.

The real cost is total cost of ownership

Comparing technologies at adoption time measures the wrong week. The exciting option usually is better in week one — that is why it is exciting. The comparison that matters covers the years after: every hour spent fighting a leaky abstraction, chasing a breaking change across a major version, or migrating off something abandoned, is an hour not spent on the product.

This asymmetry is brutal for one-person projects specifically. A team amortizes the cost of a finicky tool across specialists; a solo builder absorbs all of it, on nights and weekends, in the exact hours that were supposed to produce the work itself. The quiet-year test applies to stacks as much as servers: what does this choice cost during a year when I touch nothing? Boring technology’s answer is “nothing.” Novel technology’s answer is “you’ll find out.”

An innovation budget, spent deliberately

The useful framing is a budget: you get a small number of deliberate bets on new technology per project — one is a good number — and everything else defaults to proven.

Spend the bet where it compounds. If the project’s distinctiveness is its reading experience, spend novelty there and keep the deployment pipeline primitive. If the product is the pipeline, invert it. What is never worth the bet is infrastructure adjacent to the actual work: the newest database for a site with no queries, the experimental bundler for a site that could be plain files. Every dependency, however small, is a future migration — the same accounting that performance budgets apply to kilobytes applies to package.json lines.

Boring is not stagnant

The common objection is that this reasoning would have kept us all writing CGI scripts. It misunderstands the claim. Technologies graduate into boring: they survive their hype cycle, accumulate a decade of answered questions, and become safe defaults — that is the goal of the pipeline, not a refusal to use it. Choosing boring technology means preferring graduates, not refusing progress.

It also does not mean refusing to learn. Learn the new thing on a toy; bet the project on it after it has survived contact with other people’s production systems for a few years. The trick is not confusing the two activities, because the toy is allowed to die and the project is not.

The test I actually use

Before adopting anything, one question: when this breaks at the worst possible time, what happens? For boring technology the answer is “search the error, find the answer, apply it, done in an hour.” For exciting technology it is “read the source, file an issue, wait.” Both are survivable. Only one is survivable repeatedly, by one person, while also trying to ship.

Excitement belongs in the work. The stack’s job is to be forgettable — and the highest compliment a tool can earn is that you stopped thinking about it years ago.