In Defense of Boring: Why the Best Engineering Teams Ship on Tech You've Never Heard Of Twice

There's a team I know — I won't name them, but you've probably used a product they built — that rewrote their core data pipeline three times in four years. First it was a bespoke event-sourcing system built on a graph database that was, at the time, maybe eighteen months old as a product. Then it was a migration to a trendy streaming framework because the graph database "wasn't scaling," which in practice meant nobody on the team fully understood its consistency model anymore and every incident review ended in a shrug. Then, after the streaming framework's managed hosting provider got acquired and sunset the product with four months' notice, they migrated a third time — to Postgres and a queue, with straightforward batch jobs. It's been stable for two years. It should have been Postgres and a queue from day one.

This isn't a rare story. It's closer to the default outcome when a team optimizes for "interesting" over "boring," and I think it's worth being blunt about why that happens, because the reasons are almost never technical.

Boring was never about the tools being old

Dan McKinley's original "Choose Boring Technology" essay, written while he was at Etsy, gets misquoted constantly as "use old tools." That's not the actual argument. The argument is about innovation tokens — every team has a small, finite budget of genuinely novel things it can introduce before operational complexity outpaces the team's ability to reason about failure modes. You don't get infinite tokens. If you spend three of them on your database, your message queue, and your deployment orchestration, you have nothing left for the one thing that's actually supposed to be your innovation — the product.

Postgres is "boring" not because it's unsophisticated — it has JSON columns, full-text search, logical replication, extensions for vector search via pgvector, partitioning, and a query planner that's had decades of adversarial production traffic thrown at it. It's boring because its failure modes are extremely well documented. When Postgres does something weird, there's a Stack Overflow answer, a mailing list thread, or a colleague who's seen it before. When your bespoke graph database does something weird, you're reading source code at 1 a.m., alone, hoping the maintainer answers a GitHub issue before your SLA breaches.

The novelty tax compounds, and it compounds silently

The seductive thing about a new framework or database is that the cost is front-loaded and visible — a migration sprint, some training, a blog post announcing the switch. The cost of boring-ness debt, meanwhile, compounds quietly for years afterward: onboarding new engineers takes longer because the internal docs for your bespoke system don't exist, incident response takes longer because nobody's muscle memory covers this failure mode, and hiring gets harder because "five years of experience with our internal graph query language" isn't a résumé line anyone has.

I watched this play out concretely with a team that adopted a brand-new frontend framework about a year after its 1.0 release, specifically because it promised significantly smaller bundle sizes than React. The bundle sizes were, in fact, smaller. But the ecosystem was thin — no mature form library, no accessible component kit, a testing story that required hand-rolled adapters for Testing Library. They spent the next eighteen months building internal tooling that React's ecosystem gives you basically for free: react-hook-form, Radix or Headless UI primitives, established patterns for server state via React Query. They eventually migrated back to React, not because the new framework was bad, but because the total cost of ownership included all the ecosystem work nobody had budgeted for.

Boring is a discipline, not an excuse to stop learning

I want to head off the obvious pushback, because it's a fair one: "boring technology" can absolutely be used as cover for stagnation, for engineers who just don't want to learn anything new, or for orgs that let genuinely superior tools sit unused for years out of pure inertia. That's real, and it's its own failure mode. The discipline isn't "never adopt anything new." It's "adopt new things deliberately, in the places where the payoff clearly outweighs the operational unknowns, and be honest with yourself about which category a given decision falls into."

A concrete way I've seen teams operationalize this: before adopting anything new for a critical path, write down the actual, specific case for it, not vibes. What breaks today that this fixes, be specific and cite an incident or metric. What's the operational story if it fails at 3am, who's paged, what do they read. What's our exit plan if this project stalls or gets acquired or sunset in 18 months. And what's the innovation token cost, what are we not going to introduce this quarter as a result.

That last question is the one that kills most bad proposals honestly, because it forces someone to admit that adopting the shiny new vector database means the team doesn't have bandwidth left to also migrate CI, also rewrite the deploy pipeline, and also switch cloud providers this year — three things that were separately, quietly, also on the roadmap.

The teams that ship reliably tend to look unglamorous from outside

The infrastructure powering a huge share of the internet's actually-boring-and-actually-working systems is not exotic: Postgres or MySQL, Redis for caching, a monolith or a small number of well-understood services (not fifty microservices for a fifteen-person team), cron jobs or a straightforward job queue like Sidekiq or BullMQ instead of a bespoke workflow engine, GitHub Actions instead of a hand-rolled CI system, Docker and plain EC2 or ECS instead of a from-scratch orchestration layer. None of this makes for an exciting conference talk. It also rarely makes for a 2 a.m. page where nobody on the team has any idea what's happening.

I've come to think the actual skill being demonstrated by "boring technology" teams isn't restraint — it's taste. They still adopt new things. Claude Code and Cursor have genuinely changed how a lot of engineering teams work day to day, and the teams I respect most were fast to actually try them, not because they're novel but because the productivity case was concrete and testable within a week. Renovate and Dependabot automating dependency bumps is a newer practice too, and it's been adopted broadly precisely because the payoff is legible and the failure mode (a broken automerge) is small and recoverable. The distinguishing factor isn't age, it's whether the failure modes are well understood and the blast radius of getting it wrong is contained.

Boring is a bet on your future self

The real argument for boring technology, stripped of theory, is this: the engineer who gets paged for your system in eighteen months might not be you. It might be someone who joined the team six weeks ago. What does their 2 a.m. look like — a Postgres slow query log and twenty years of collective internet knowledge to search against, or a GitHub issue tracker with four stars and a maintainer who hasn't committed in six months? Every technology choice is, among other things, a bet on how much help future-you or future-your-teammate will have when it breaks. Boring technology is, more often than not, the bet with better odds.