Choosing boring technology on purpose

Dan McKinley's framing is the sharpest tool here: imagine your team gets a small, fixed number of innovation tokens, maybe three, to spend on genuinely new technology. Everything else should be as boring and proven as possible. Spend a token on a new database, a new language, and a new deployment model at once, and you have blown the budget before you have shipped anything.

The reason the budget is small is that new technology fails in ways you cannot anticipate, and every novel component multiplies the unknowns. Boring technology has a known failure surface: Postgres has been broken and fixed by millions of teams, so whatever goes wrong, someone has written the Stack Overflow answer. Your bespoke event-sourced graph database has an audience of one for its incident reports, and that audience is you.

The canonical example is the database, because it is where teams most love to over-engineer. Postgres is a relational store, a JSON document store, a full-text search engine, a queue with SKIP LOCKED, a geospatial database with PostGIS, and a pub-sub system with LISTEN/NOTIFY. Most products that reached for a separate document store, search cluster, and queue could have run all three inside one Postgres instance for years.

The point is not that specialized tools are never right; it is that you should feel the specific pain that justifies them before you adopt them. Running one database you deeply understand is operationally cheaper than running four you understand shallowly, and “we might need to scale to Google's size” is not pain, it is a fantasy that costs you real velocity today for a problem you will likely never have.

A stack is not just what you build on, it is what you can staff and keep running for five years. Choosing a mainstream framework means you can hire people who already know it, onboard them in days, and find answers instantly, whereas a niche language turns every hire into a bet and every departure into a bus-factor crisis. The exotic choice that made the founding engineer feel clever becomes the reason the company cannot grow the team.

Maintenance is the quiet majority of a system's life. Boring technology tends to have a long support horizon, security patches, and a large enough community that critical bugs get found and fixed by people who are not you. A trendy framework at version 0.x can pivot, get abandoned, or ship breaking changes on a whim, and you inherit the migration whether you have time for it or not.

Boring by default does not mean boring forever. Spend an innovation token when the new technology attacks your core differentiator, the thing customers actually pay you for, rather than plumbing they never see. If you are building a real-time collaboration product, an investment in CRDTs is spending your token on the product itself, which is exactly right.

The test is whether the novelty buys you a capability you cannot get otherwise, and whether you can articulate the concrete pain it relieves. “It is faster to write” or “it is what the cool companies use” are not that; “our existing stack physically cannot do sub-50ms sync” is. Spend deliberately, on your differentiator, and keep the plumbing dull.

The compounding advantage of a boring stack is that it frees your scarce attention for the problems that are actually yours. Every hour not spent debugging a bleeding-edge runtime is an hour spent on the product experience your competitors are also fighting for. Boring infrastructure is what lets you be interesting where it counts.

There is also a cultural benefit: boring choices are legible to the whole team and to whoever inherits the codebase. New engineers can reason about a standard Rails or Django or Express app on day one, which means they contribute sooner and break things less. Legibility is a form of speed, and it is one the exotic stack quietly taxes.