There’s a particular kind of confidence in choosing a tool no one needs to explain. It leaves more of the team’s attention for the problem itself: the shape of the data, the failure modes, and the experience of the person waiting for an answer.

If you’ve ever been paged at 3am because some “cutting-edge” component decided to behave like a black box with opinions, you already know the thesis of this post. You just might not have had the words for it yet.

This is a longer, more detailed take on why “boring” technology is often the most ambitious choice you can make—especially when your team has to own the system long after launch day fireworks have faded.

Boring Is a Property of Knowledge, Not of Age

Let’s start by killing a myth: “boring” does not mean “old and bad.” It means well-understood.

Dan McKinley’s classic essay Choose Boring Technology frames it cleanly: boring tech has known capabilities and, more importantly, known failure modes. You can find war stories, post-mortems, and Stack Overflow threads for the exact mess you’re currently in.

In 2026, this distinction matters more than ever. AI coding tools have dramatically reduced the adoption cost of new technology: you can spin up a prototype with an unfamiliar database or runtime in an afternoon. What hasn’t changed is the operations cost: the accumulated community experience of what happens when things go wrong at scale.

Ask yourself:

  • If this tool misbehaves at 3am, how many people can debug it without reading its source?
  • How many companies are running this in production at my scale?
  • Where are the post-mortems?

PostgreSQL in 2026 is boring. A bespoke queue framework written last year by a startup that’s now a 404 page is exciting in exactly the wrong sense.

Boring technology answers the 3am question with a number you like. Novel technology answers with a blog post you wrote yourself.

The Innovation Token Budget

McKinley’s “innovation tokens” model is still one of the cleanest ways to think about this.

The idea is simple:

  • Assume your company has roughly three innovation tokens to spend.
  • Each novel technology choice costs one token.
  • Tokens are scarce and not easily replenished.

Examples of token spenders:

  • Writing your backend in a trendy new runtime.
  • Adopting a database that’s been out for less than a year.
  • Rolling your own service discovery, queue, or configuration system.

Any of these might be sensible if you’re a consultancy, a database company, or your product is that technology. But if you’re trying to reinvent payments, logistics, healthcare, or anything where the tech is a means rather than the end, burning tokens on infrastructure novelty is a fantastic way to delay success.

The uncomfortable truth: most companies are not special enough to justify special infrastructure. Your competitive advantage is almost never “we use the coolest stack.” It’s usually “we understand this domain better than anyone else.”

The Cost Curve Nobody Budgets For

Novel choices are priced at evaluation time:

  • A pleasant afternoon of benchmarks.
  • A slick demo.
  • A few “hmm, interesting” Slack threads.

Their real cost arrives later, as maintenance:

  • The upgrade path nobody owns.
  • The edge case only the original author understands (who has since left for a “more innovative” startup).
  • The hiring pool that quietly shrinks with every exotic dependency.
  • The internal wiki page titled “How Our Custom Retry Logic Actually Works (Please Don’t Touch).”

Boring choices invert this curve. They cost you a slightly less impressive demo, a marginally slower time-to-prototype, and the humility of admitting you’re not that special (yet). In return, they give you years of uneventful operation, a large pool of engineers who already know the tool, and documentation and tooling that assumes you’re not the first person to hit this problem.

Over any realistic horizon, “uneventful” wins. Uneventful is what lets you sleep. Uneventful is what lets you ship features instead of war stories.

Known Unknowns vs. Unknown Unknowns

When you choose technology, you’re choosing a set of unknowns.

McKinley borrows from Rumsfeld to make the point:

  • Known unknowns: “We don’t know what happens when this database hits 100% CPU.”
  • Unknown unknowns: “We didn’t even consider that writing stats would cause GC pauses.”

Both sets are non-empty, even for decades-old tech. But for shiny new technology, the magnitude of unknown unknowns is significantly larger.

With boring tech, people have already hit your problem, the GitHub issue has 47 comments and a merged fix, the post-mortem is on a blog somewhere, and the conference talk exists.

With novel tech, you file a GitHub issue at 2am. AI helps you write the reproduction case. It cannot fix the bug that doesn’t exist in the project’s history yet. It cannot generate the Stack Overflow answer that nobody has written.

AI compresses adoption cost. It does not compress operations maturity.

When Novelty Actually Earns Its Place

This isn’t a purist manifesto. New tools should be used—just not for marginal convenience.

Novelty earns its place when it buys a meaningful capability, not a slight syntactic sugar rush. Use this filter:

  1. Is this capability central to the product, or just incidental polish? If your product is “real-time collaborative editing,” then a novel CRDT library might be worth it. If your product is “online store,” probably not.
  2. Can the team clearly articulate what happens when this tool fails? If the answer is “we’ll figure it out,” that’s a red flag.
  3. Is there someone who will genuinely enjoy owning it? Someone needs to pay the novelty tax voluntarily, not by accident.

Vector databases are a perfect example. For some workloads, they’re absolutely worth it. For others, pgvector on the Postgres you already operate is the more ambitious choice—not because it’s cooler, but because ambition should aim at outcomes, not stack diagrams.

Optimize Globally, Not Locally

One of the most seductive phrases in engineering is: “Let’s use the best tool for the job.”

It sounds rational. It’s often a trap.

The problem isn’t the sentiment; it’s the scope. “Best for the job” usually means “best for this one micro-problem,” ignoring operational overhead, cognitive load for the rest of the team, hiring implications, and long-term maintenance costs.

As McKinley puts it: your job is keeping the company in business. The “best” tool is the one that occupies the “least worst” position for as many of your problems as possible.

Every new technology you add comes with baggage: you have to monitor the thing, you need to write unit tests, new hires need to learn it, you need init scripts, deployment pipelines, backup strategies, observability hooks. This adds up fast.

“Best tool for the job” thinking takes a myopic view of both “best” and “job.” Your job is not just this feature. Your job is the entire system, over years.

A Practical Process for Adding New Technology

You don’t need a heavy governance process. You do need a conversation. A lightweight gauntlet that works well:

  1. Ask: “How would we solve this without adding anything new?” This detects situations where the “problem” is actually “someone really wants to use this technology.” If that’s the case, abort.
  2. Write down exactly what’s prohibitive about the current stack. Not vibes. Specific, concrete blockers. If you can’t articulate them, you probably don’t need a new tool.
  3. If the new tool overlaps with existing ones, set clear migration expectations. “We’re committed to migrating” with a proposed timeline. This avoids proliferating locally optimal solutions that become global nightmares.
  4. Make it a company-wide conversation. New tech eventually has company-wide effects.

This process isn’t daunting. It’s a handful of questions as homework, followed by a meeting.

Real-World Patterns From 2024–2026

In the last couple of years, enough teams have made interesting technology choices that the pattern is now visible.

Bun instead of Node.js — Migrating from Node to Bun with AI assistance was fast: updated configs, new scripts, working tests within days. Six months later, some teams hit Node compatibility gaps and memory management quirks under sustained load. The bugs were open on GitHub. Fixes were in progress. The teams were in production and waiting.

Cloudflare Workers — Attractive execution model: no cold starts, global distribution, good performance for appropriate workloads. But the constraints (no Node built-ins, 128MB memory ceiling, CPU time limits, no persistent filesystem) are behaviorally surprising at scale. When teams hit those limits, the debugging path was narrower than Lambda, where the failure taxonomy is years deep.

Distributed SQL / SQLite-flavored databases — Tools like Turso, Neon, and similar attracted teams with pricing and global distribution models. For read-heavy workloads with predictable traffic, many have worked well. For heavier transactional use as data volume grew, teams found themselves past the edge of what the community had mapped.

None of these tools are bad choices. The question in each case was not whether the technology was good, but whether the community had already paid the operations cost at the scale each team needed.

What “Boring” Actually Means in 2026

Boring technology is not: the language from your first job, the framework your previous employer used a decade ago, or anything old by default. Chronological age is a rough proxy for operational maturity, and it’s often the wrong one.

Boring technology is technology where the operations cost has already been paid by the community at the scale you’re operating.

Examples:

  • Postgres at 100 GB is boring. Vacuuming strategies are documented. Index tuning guides cover most real workloads.
  • A novel distributed SQL database at 100 GB may be technically excellent, but boring it is not: the community hasn’t paid the operations cost at that scale.
  • Redis for a session store is boring. Valkey, the Redis-compatible fork backed by major clouds, is also boring enough.
  • AWS Lambda for background jobs is boring.
  • Running your own Kubernetes cluster as a ten-person team is not boring—not because Kubernetes is new, but because your specific team has not yet absorbed the operational cost of running it.

The Updated Rule for 2026

McKinley’s innovation token model still holds, with one update:

Old model: Each novel technology choice costs an innovation token. Tokens should go toward what differentiates the product rather than the infrastructure.

2026 update: AI has partially refunded the adoption portion of each token. You can try more things faster. The operations cost of each token is unchanged.

For experiments, internal tools, and early-stage prototypes, the lower adoption cost is a real benefit. For production systems that engineers will page into at 2am in three years, the gate should be operations maturity, not adoption speed.

Before choosing something novel for a production path, ask: How many people have run this at my scale? Where are the post-mortems? Who will I hire to maintain it?

If the answers are good, the tool has probably graduated to “boring enough” for production, regardless of when it shipped. If the answers aren’t there yet, the fact that AI can set it up in an afternoon is not the signal you’re looking for.

From Architect to Entrepreneur

Julien Hurault’s “Boring Engineering Manifesto” adds another useful angle: be output-driven first.

Instead of designing for a hypothetical future at massive scale, ask: What is the question we need to answer first? What is the smallest system that answers it well?

Then: ship first, get feedback, tweak later. This is the MVP mindset applied to architecture. MVP doesn’t mean trash output. It means doing one very specific thing—and doing it really well.

A boring system is as little code as possible, optimized for easy maintenance rather than fancy features, understandable by the largest number of engineers possible, and designed without assuming massive growth.

The Uncomfortable (But Liberating) Summary

A well-modeled database, a clear API, and an observable background job are still brutally hard to beat for most problems most teams face.

Choosing them isn’t a failure of imagination. It’s imagination aimed where it actually compounds: at the product, at the people who inherit what you build, and at the future version of you who gets paged at 3am and would really like to know what the hell is going on.

Boring technology is not a lack of vision. It’s a deliberate decision to spend your innovation tokens on the things that differentiate your product, not on re-inventing infrastructure that already works.

In a world obsessed with the new, choosing boring is quietly rebellious. And often, it’s the most ambitious thing you can do.