When to Choose Boring Technology
Dan McKinley wrote the canonical essay. Here's how I apply it twelve years later.
Boring technology is a strategy, not an aesthetic. Twelve years after Dan McKinley's original essay, the principle has held up better than almost any other piece of architectural advice I know.
Dan McKinley's Choose Boring Technology is one of the few engineering essays I re-read every year. Twelve years on, it's even more correct than when he wrote it. This is how I apply it on real client work.
The original argument, in one paragraph
Every technology choice you make spends an "innovation token". You have a small budget, maybe three or four tokens for a new project. Spend them on the one or two areas that genuinely differentiate your product. For everything else, pick the option that's been working in production for a decade. Postgres. Linux. Boring.
That's the essay. The rest is application.
What "boring" means in 2026
Boring is not the same as old. It means understood, predictable, with mature tooling and a large community. The boring stack today is more or less:
- Postgres for the primary database.
- Redis for cache and rate limiting.
- Linux on EC2 or equivalent for compute.
- Spring Boot or Express or Django for the backend, depending on language preference.
- Next.js for the frontend if you're shipping a product website.
- GitHub Actions for CI.
- Datadog or Grafana for observability.
That stack is so boring it's almost embarrassing to write. It will also take you to a billion in revenue without architectural pain.
How I count innovation tokens on a real project
When I scope a new product, I literally write down where the team is spending their tokens. Recent example, a fintech build I helped on:
- Token 1: a custom risk engine in Java, because that's the product.
- Token 2: real-time fraud streaming on Kafka, because the latency mattered.
- Token 3: pgvector for semantic search across transaction history, because nobody else was doing it.
Everything else - the API layer, auth, deploys, the frontend, the queue - was boring as a brick. Spring Boot, JWT for service-to-service tokens, server-side sessions, GitHub Actions, vanilla Postgres for storage.
The team shipped on time. The boring choices freed all our cognitive load for the three things that mattered.
When to spend a token
I spend a token only if:
- The technology is genuinely better on a measurable axis (10x faster, 10x cheaper, eliminates a class of bugs).
- The team has someone who can operate it under failure.
- The migration path away exists and is documented.
If any of those three is missing, I keep the token in my pocket.
When boring fails
Boring is not always right. There are real cases where the boring choice is the wrong choice:
- Your product's core is non-boring. If you're building a vector database, you can't use a boring vector store, you have to build one. The novel work has to be in the area that makes you different.
- Boring is genuinely worse for your scale. A 5000-engineer company has different needs than a 5-engineer one. Internal tooling at FAANG is interesting because it solves problems most companies will never have.
- You have a recruiting reason. Some teams genuinely cannot hire if their stack is too boring. This is a real constraint, but it's a smaller one than people think.
The hidden cost of exciting tech
What I see most often: a team picks an exciting database (or runtime, or framework) because it solves a problem they don't yet have. Two years later, the original advocate has left. The remaining team is now the on-call rotation for a piece of technology none of them are experts in. Every incident takes 3x as long. Hiring becomes harder.
That cost almost never shows up on the original ROI analysis. It's the most expensive line item over a five year period.
The practical filter I run
Before adopting a new technology, I run three questions:
- Are there 10+ companies my size or larger using this in production for 3+ years? If not, I'm taking on bleeding-edge risk.
- If the maintainer disappears, can my team still operate it? If no, that's a single point of failure I cannot accept.
- Will I be embarrassed if I'm still using this in 2030? If yes, that's a sign I'm picking for fashion, not function.
If a technology passes all three, it's a candidate. If it fails any one, it's not.
The sharper insight
Boring technology compounds, exciting technology decays. Every year a boring technology is in production, the documentation gets better, the failure modes are more catalogued, the talent pool grows. Every year an exciting technology is in production, the original team thins out, the maintainers move on, and the docs slowly age.
The choice between exciting and boring is not really about today. It's about what your codebase looks like in 2030. Almost all the teams I've seen pick excitement live to regret it. Almost none of the teams that picked boring ever regretted that part of the decision.
For a related take on what specifically I'd build with, see the zero to launch stack.