The case for boring technology

Every few months, the same itch. A framework announcement lands, the demo is forty seconds of effortless magic, and my own stack — working, deployed, paid for in lessons — suddenly looks like a rotary phone. I have rewritten projects on that itch, and I can report with precision what the rewrites delivered: two weeks of momentum, followed by eighteen months of discovering, one production surprise at a time, everything the old stack had been silently handling. The itch never announces its bill up front. That asymmetry, more than any particular technology, is what this post is about.

The best framing I know comes from Dan McKinley’s essay "Choose Boring Technology," written from inside Etsy’s engineering culture: imagine your company gets a fixed allowance of innovation tokens — he suggests about three — and every non-standard technology choice spends one, permanently, in ongoing attention. The essay was aimed at companies. Scaled down to a one-person operation running a portfolio of free browser tools, the allowance is smaller and the accounting is harsher, because every token I spend gets redeemed in the same currency: my own evenings.

What follows is the case as I have come to hold it after several spends, one refund, and a couple of write-offs. What a token actually costs and when the bill arrives. Why boring describes knowledge rather than age. Why the boring choice should own your data, your auth, and your payments without debate. And where novelty is not only acceptable but the correct move — because a version of this argument that ends "never try anything" would be both wrong and no way to live.

The token metaphor works because it prices the right thing. Adopting a technology is not a one-time learning cost; it is a subscription to that technology’s entire future — its bugs, its breaking changes, its security advisories, its community’s attention span. The mainstream choice spreads that subscription across a million other users who hit the bugs first, write the blog posts, and pressure the maintainers. The novel choice concentrates it on you. When my Postgres query plan goes weird, the answer exists on the internet before I finish typing the question. When the clever niche datastore misbehaves, I am not searching for the answer; I am the search result other people will find next year.

A company of three hundred can float three tokens because redemption is distributed — someone owns the weird queue, someone else owns the exotic build system. Alone, every token redeems against the same person, and worse, redemption is bursty: the exotic choice never asks for its interest payments on a quiet Tuesday. It asks during launches, during traffic spikes, during the week you had planned to build the feature that makes money. I budget one token at a time. Not because a second experiment would kill me, but because two simultaneous sources of novel failure make every incident a murder mystery with two suspects.

The subtlest part of the metaphor is that tokens get spent whether or not you notice spending them. Nobody convenes a meeting to decide "we will now adopt an immature ORM"; someone reaches for it in a branch, it works in the demo, and the subscription begins. The defense is not vigilance — vigilance runs out — but a default: mainstream unless a written argument says otherwise. I make that argument in a ten-line decision record of the kind described in Documenting decisions: the ten-line ADR that saves future you, and the friction of writing "because" has canceled more adoptions than any amount of discipline.

New-framework costs are back-loaded, which is exactly why the itch wins arguments in the moment: at adoption time you experience only the delightful parts — the fresh docs, the fast demo, the sense of moving with the current. The costs are structured like a balloon mortgage. Year one is fine. Year two is the major-version migration that renames half the API, the plugin you depend on whose maintainer took a job and stopped answering, the Stack Overflow tag where your exact error has one result and it is your own unanswered question from a month earlier.

I watched this arc from the inside on a product we eventually shelved — the full story is in Why we shelved Novus Stream Studio: a second-screen idea that was really several apps — where part of the weight was a stack of enthusiastic choices that each demanded its own upkeep. None of them was individually wrong. Collectively they meant the project started every month owing a maintenance tax before it earned its first feature, and a side project that begins each month in debt does not survive contact with a finite person. The product had other problems too, but the stack made every one of them more expensive to address.

The line items repeat so reliably across projects — mine and the postmortems I read — that I keep them as a literal checklist to review while the demo glow is still warm:

The word boring does the argument a disservice, so let me define it: a boring technology is one whose failure modes are catalogued. Postgres is boring not because it is old but because decades of production use mean that essentially every way it can hurt you is documented, monitorable, and answered. SQLite is boring and is also, by many measures, the most widely deployed software artifact in history. Boring is a property of accumulated collective experience — how much of the map has been filled in — not a property of the copyright date.

That definition cuts both ways, and this is where the boring-technology argument gets misquoted into "never upgrade anything." Old and dying is not boring in the useful sense: the framework nobody maintains has unknown future failure modes too, because nobody will be there when they appear. A technology can even be young and boring-ish when it is a thin layer over catalogued parts. The axis that matters runs from "failures are searchable" to "failures are yours alone," and age is only loosely correlated with position on it.

The test I actually apply, standing in the framework store: can I describe, right now, three specific ways this technology will fail me, and do I know what I would do about each? For the boring parts of my stack I can recite them. For last month’s hot release I cannot — not because it is bad, but because nobody on earth can yet; the catalogue does not exist. Choosing it means volunteering to write the catalogue with my own incidents, and that is exactly what the token buys: authorship of failure documentation for a tool I just wanted to use.

If the token budget forces priorities, the order is set by blast radius and reversibility, and three domains sit at the top of every audit I have done. Data, because storage mistakes are the only ones that compound silently — a bad UI ships and is visibly bad, but a subtle corruption or a lossy migration is discovered months later, at full size, with no undo. Auth, because its failure mode is not a bug but a breach, and the gap between a battle-tested session library and a hand-rolled one is a catalogue of attacks the library’s authors have already survived. Payments, because the counterparty is money and the referee is a regulator.

My practice, and my advice, is total unoriginality in all three: the most mainstream storage you can operate, auth from the platform or the most-audited library in your ecosystem, and payments delegated wholesale to a processor whose entire business is surviving that referee. These are domains where differentiation is impossible anyway. No user has ever chosen a product for its inventive session-token scheme, and several products have died of one. The interesting version of you has nothing to win here; the boring version has everything to not lose.

Notice the pattern in the three: they are the layers you cannot cheaply exit. A database migration under load, an auth cutover with live sessions, a billing swap with active subscriptions — each is open-heart surgery, which means the choice you make early is close to permanent, which means it is precisely where you want the option with the filled-in map. Reversibility is the hinge of the whole framework: spend novelty where mistakes are cheap to unwind, spend boredom where they are not.

The honest version of this argument has to say where the itch may be scratched, because a policy of pure abstinence fails the way all abstinence policies fail. The answer is the leaves — the parts of the system with one dependent, no state, and an afternoon-sized exit. A card animation, a chart renderer, a CSS layout technique, the confetti on an empty state: try anything there. If the shiny library is abandoned next year, the write-off is one component, replaced in an hour, with no migration and no data at risk. Leaf novelty is how you learn what the new generation of tools is actually like without underwriting it.

The structural property that makes a leaf a leaf is directionality: leaves depend on the core, and nothing depends on leaves. Novelty in a leaf is a contained experiment; novelty in the core is a commitment every future feature inherits. The failure pattern to watch for is leaf creep — the experimental state library that was "just for this widget" and is load-bearing across nine components by spring. My rule is that an experiment stays an experiment until a written decision promotes it, which sounds bureaucratic and is, in practice, one ten-line file and five minutes of admitting what I am actually doing.

Leaf experiments also produce the only trustworthy evaluations. Reading a comparison post tells you how a tool demos; running it in one real corner of a real product for two months tells you how it maintains, which is the only question that matters. Two of my current mainstream choices started as leaf trials that earned promotion, and at least three fashionable tools died quietly in the same nursery, at a total cost of maybe four hours. That is what an innovation-token refund looks like: learning purchased at leaf prices instead of core prices.

Here is my own ledger, for concreteness. This portfolio’s single deliberate token went to on-device machine learning in the browser — background removal and audio visualization running entirely on the visitor’s hardware. It was an exotic choice when I made it, thin on documentation and rich in original failure modes, and it has consumed exactly the ongoing attention the metaphor predicts. It was also the correct spend, because it is the differentiator: the reason the tools can be free, private, and instant is that no server touches the work. That is the one place novelty pays rent, so it gets the whole budget.

Everything surrounding that token is aggressively unoriginal, on purpose. The site is a Next.js app deployed the most conventional way possible — the workflow in Shipping on Vercel solo: the deploy and preview workflow that keeps overhead near zero is almost embarrassingly stock — and the content pages ship as static HTML for the reasons argued in Static-first: when a small site doesn't need a single-page app. Files sit on a CDN. There is no queue, no cache layer, no microservice, no storage doing anything interesting. When something breaks at the boring layer, the fix is a search away, which preserves my scarce original-debugging capacity for the ML layer, where no search can save me.

The unglamorous consequence is an operation one person can actually hold: the cost accounting in Keeping monthly overhead low while running a portfolio of apps only works because the stack beneath it refuses to be interesting. I think of it as a contrast budget. A portfolio that is novel in one dimension and boring in every other is legible — when something misbehaves, I know immediately which kind of problem I am having. A portfolio that is moderately novel everywhere is a fog, and fog is what actually burns solo developers out; not the hard problems, the unlocatable ones.

Compressed to something you can run on a Thursday afternoon while a demo is still glowing in the next tab, my rule is four questions in order. Does this choice touch data, auth, or payments? If yes, boring, end of discussion. Is this the thing my product is actually differentiated by? If yes, this is what tokens exist for — spend deliberately and write it down. Could I rip it out in one afternoon if the maintainer vanished? If yes, it is a leaf; play. Otherwise — core-adjacent, not differentiating, not cheaply reversible — the default is the most mainstream tool that solves the problem, chosen without shame.

Two amendments keep the rule from calcifying. First, re-evaluate on a schedule instead of on impulse: once a year, deliberately, I look at what the ecosystem has settled on and ask whether any of my boring choices has drifted from "catalogued" to "dying," because dying tech fails the boring test too. Migration on a calendar is planned work; migration on an itch is a mood with a diff attached. Second, genuine friction is data: when I notice I am writing framework-shaped workarounds every week, the boring option may be fighting the problem, and the annual review is where that evidence gets weighed rather than acted on at midnight.

The itch never goes away, and it should not; it is the same instinct that finds real step changes. The discipline is only about where it lands. Point it at a leaf, let it prove something in a corner where failure costs an afternoon, and promote the winners with your eyes open. What the boring posture actually buys is not stasis — this stack has changed plenty in two years — but the thing a small operation runs on: predictable failure, searchable errors, and evenings that belong to the product instead of to the stack that was supposed to be serving it.