Dan McKinley's "Choose Boring Technology" talk from 2015 just resurfaced on Hacker News with over 400 upvotes — and it's more relevant in 2026 than it was when he first delivered it. If you're building anything in the age of AI, microservices, and weekly framework releases, you need to understand this concept.
The Core Thesis
McKinley's argument is simple: when choosing technology for a project, boring is better. "Boring" doesn't mean bad — it means well-understood, widely deployed, thoroughly documented, and predictably behaved.
Boring technology is technology that:
- Has been in production for years, not weeks
- Has extensive documentation and community knowledge
- Fails in predictable, well-understood ways
- Has known solutions to known problems
- Doesn't require you to be the first to discover its edge cases
Exciting technology, by contrast, is new, innovative, and full of surprises — including surprises you don't want in production.
The Innovation Premium
Every time you choose a new, exciting technology, you pay what McKinley calls the "innovation premium" — the extra time, effort, and risk that comes from being an early adopter. This premium includes:
- Learning the technology: Reading docs, writing test code, making beginner mistakes
- Discovering undocumented behavior: Things the docs don't mention, usually at the worst possible time
- Building internal tooling: Because the ecosystem isn't mature enough to have the tools you need
- Fixing bugs in dependencies: Because you're one of the first to find them
- Being the support team: When things go wrong, you can't Google the answer — you ARE the answer
The innovation premium is real, and it compounds. Every exciting technology choice in your stack adds another premium, and those premiums multiply, not add.
The Three Technology Rule
McKinley proposes a guideline: for any given project, choose at most one new technology. If your stack already includes PostgreSQL (boring), React (boring), and Docker (boring), you can afford to experiment with one new thing — say, a new AI inference framework. But if your stack includes a new language, a new database, a new deployment tool, and a new AI framework, you're paying four innovation premiums simultaneously, and you will spend most of your time managing the consequences of your technology choices rather than building your product.
This rule is particularly relevant in 2026, when the temptation to adopt new AI tools, new vector databases, new agent frameworks, and new model-serving infrastructure is overwhelming. Every one of those is an innovation premium.
Why Boring Technology Wins
1. Predictable Failure Modes
Boring technology fails in ways that people have documented. When PostgreSQL crashes, there are runbooks, Stack Overflow answers, and colleagues who have seen it before. When a brand-new database crashes, you're on your own.
2. Hiring and Onboarding
Boring technology means you can hire from a larger talent pool. A developer who knows React, PostgreSQL, and Node.js is easy to find. A developer who knows your custom AI agent framework built on a new language using a new vector database is... you.
3. Operational Maturity
Boring technology has monitoring tools, alerting systems, dashboards, and best practices. New technology requires you to build all of those yourself, which is time you're not spending on your actual product.
4. Risk Management
Boring technology has a track record. You know its uptime characteristics, its scaling limits, its security profile. New technology is an unknown risk — and in production, unknown risks have a way of becoming known problems at the worst possible moment.
The Counter-Argument
The pushback on boring technology usually goes something like: "But if everyone chooses boring technology, nothing ever improves!"
McKinley addresses this directly: the key is strategic boring-ness. You choose boring technology for the parts of your system that need to be reliable — your database, your message queue, your authentication system. You choose exciting technology for the parts where innovation gives you a competitive advantage — your AI model, your user interface, your recommendation algorithm.
The trick is knowing which parts of your system can tolerate excitement and which parts need boring reliability. If you're not sure, the answer is: it needs to be boring.
Applying This in 2026
AI Infrastructure
Use boring technology for the infrastructure that supports your AI features:
- Database: PostgreSQL (boring) with pgvector extension for embeddings
- Message queue: Redis or RabbitMQ (boring)
- Deployment: Docker + standard cloud provider (boring)
- Monitoring: Prometheus + Grafana (boring)
Save your innovation budget for the AI layer itself — the model selection, the prompt engineering, the agent architecture. That's where excitement gives you an edge.
The AI Framework Trap
Every week, a new AI framework is released with a catchy name and an impressive demo. LangChain, LlamaIndex, CrewAI, AutoGen — they're all exciting, and they're all innovation premiums. If you adopt three of them, you're paying three premiums and getting the benefit of maybe one.
Choose one. Use it boringly. Get it into production. Then, if you need to, experiment with something new — but only after the first one is boring.
The Long Game
The companies that succeed long-term aren't the ones with the most exciting technology stacks. They're the ones that ship reliable products, consistently, year after year. Boring technology enables consistency. Exciting technology enables chaos.
McKinley's talk was delivered in 2015, about decisions being made in 2015, using examples from 2005 and 2010. The fact that it's being upvoted on Hacker News in 2026 — eleven years later — is proof that the principle is timeless.
Boring technology will still be here in 2035. The exciting stuff from today will either become boring (in which case you can adopt it safely) or be forgotten (in which case you're glad you waited).
Conclusion
Choose boring technology. Not because innovation is bad, but because innovation is expensive — and you only have so much budget. Spend it where it matters, not where it's flashy.
Your future self, debugging a production issue at 3 AM, will thank you for choosing the technology with a Stack Overflow answer from 2019.
Dan McKinley's original talk and essay are essential reading for anyone making technology decisions. The fact that it's still being discussed a decade later tells you everything you need to know.
Top comments (0)