We have all been there. You see a YouTube video showcasing the latest JavaScript framework. The benchmarks look incredible. The syntax is cleaner. The performance is 10% better. The comments are filled with engineers praising how much faster they ship now.
We in the tech industry have this pull toward new technology. We want to work on the latest and greatest. We worry that staying with older tools means falling behind. The fear of becoming irrelevant drives us toward whatever just hit the front page of Hacker News.
But here's what we forget: we don't ship code, we ship products that solve problems for real people. The code is just the means to that end. The framework, the language, the database—those are tools to build something people need. When we spend six months migrating to a new framework, we're not shipping product, we're rewriting the tool we use to ship product.
So we pitch it anyway. "This new framework will make us so much faster." The team agrees it looks promising. The migration starts.
Six months later, you have a system that does exactly what the old one did, except now only two people understand it. Production incidents take longer to debug because Stack Overflow has five answers instead of five thousand. New hires need three weeks of training instead of three days. The 10% performance gain nobody can measure costs you 40% of your team's focus. Your users didn't get six months of new features—they got the same product running on different infrastructure they can't see and don't care about.
The technology that wins isn't the newest or most interesting. It's the one boring enough that you stop thinking about the code and start solving actual problems.
What Boring Actually Means
Boring technology isn't old technology. PostgreSQL is boring. React is boring. Django is boring. Node.js is boring. These are mature tools with a decade of production use, extensive documentation, and a community large enough that someone has already hit your exact problem.
Boring means predictable. You know how it fails and you know how to fix it. When something breaks, you can find the answer without reading source code. Your new hires can become productive without a month of internal training. The patterns are documented, the edge cases are understood, and the operational characteristics are well-known.
Dan McKinley's "Choose Boring Technology" makes this explicit: every team has a limited innovation budget. Spend it on problems that actually matter to your business, not on rewriting working systems in a newer language.
The Hidden Costs of New
New technology looks cheaper than it is. The tutorial makes it seem simple. The benchmarks show it's faster. The GitHub stars suggest momentum. What you don't see until you're committed are the costs that show up later.
Documentation gaps appear once you leave the happy path. The tutorial works perfectly, but edge cases have three GitHub issues with no resolution. Production debugging means reading implementation code because the error messages assume you're a contributor.
The hiring pool shrinks dramatically. You chose Svelte over React because it's more elegant, and now you're filtering out 90% of frontend candidates because they haven't used it. The ones who have often just did a tutorial. You spend months training people who could have been productive in week one.
Maintenance becomes a constant burden. Every dependency updates every month. Breaking changes happen without warning because semantic versioning is more guideline than rule. Your team spends 20% of their time just keeping the build working instead of adding features.
Integration friction appears everywhere. Your monitoring tool has first-class support for Express but not Fastify. Your deployment platform optimized for Next.js but your new framework needs custom configuration. Everything that should be automatic now requires engineering time.
When Innovation Creates Drag
A team I worked with adopted GraphQL because REST felt old and they wanted more flexible data fetching. The pitch made sense: clients could request exactly what they need, no over-fetching, better performance. Two years later, they're still debugging N+1 query problems, arguing about schema design, and dealing with complexity they didn't anticipate.
Here's what actually happened: their clients query everything anyway. The flexibility GraphQL promised turned into every frontend developer writing queries that pull entire object graphs because it's easier than thinking about what they actually need. The REST API they replaced had solved the same problems with simple endpoints that returned predictable shapes. No schema stitching, no resolver complexity, no performance debugging across layers.
The real issue wasn't that REST was insufficient. The real issue was that GraphQL is overengineering for most applications. It solves problems that sound interesting in conference talks but rarely exist in practice. Now they're solving GraphQL problems instead of user problems.
The pattern repeats across different choices. WebSockets instead of HTTP polling when you check for updates every 30 seconds. Microservices instead of modules when your team has eight engineers. Kubernetes instead of VMs when you deploy twice a week. Each choice adds operational complexity, requires expertise your team doesn't have yet, and pulls focus from the work that actually matters to the people using your product.
We ship products, not architecture. Every hour spent on infrastructure that users can't see is an hour not spent on problems they actually have.
The Innovation Budget
McKinley's framework is simple: you get about three innovation tokens, so spend them wisely.
If you're building a real-time collaboration product, real-time sync is worth a token because it's part of the problem you're solving. If you're building a data pipeline, stream processing might be worth it because it directly serves your users. If you're doing machine learning, use Python and accept the deployment complexity because the ML is the product.
But if you're building a standard web application with CRUD operations and some business logic, every token spent on infrastructure is one you can't spend on the product. Most startups die because they didn't ship enough features, not because they picked Express over Fastify. They fail because they solved the wrong problems.
Your users don't care what database you use—they care whether your product solves their problem. Your job is to solve their problem as quickly as possible, not to build the most interesting technical system.
Basecamp runs on Rails, MySQL, and Redis. GitHub runs on Rails and MySQL. Stack Overflow runs on C# and SQL Server. Shopify handles Black Friday on Rails. None of these companies are held back by their boring technology. They're succeeding because they focused on problems their users have, not on the elegance of their stack.
The Decision Framework
When evaluating new technology, ask these questions:
Does this solve a problem our users or stakeholders have? Not a problem we might have at 10x scale or a problem that sounds interesting to engineers, but a problem that's preventing us from shipping value to users right now.
Can we solve it with what we already use? Before adopting server-side rendering, did you try caching? Before switching to microservices, did you try modules? The boring solution is usually simpler than the exciting one, and simpler means you ship faster.
Will this still be maintained in five years? Look at the team behind it. Is this backed by a company with staying power, or is it a side project from someone who might get bored? Corporate backing isn't everything, but betting your infrastructure on one person's free time is risky.
Do we have expertise, or will we build it? New technology means learning operational characteristics, failure modes, and performance patterns. That takes time. Are you willing to spend six months becoming experts, or do you need to ship next quarter? The honest answer often points toward boring tech.
What's the migration cost if we're wrong? If this doesn't work out, what does getting back cost? Boring technology usually has clear migration paths because so many others have walked that road. Cutting-edge stuff often leaves you stranded.
What About Innovation?
This isn't an argument against ever using new technology. It's an argument for being deliberate about where you spend your innovation budget.
LinkedIn's real-time infrastructure is worth the complexity because real-time is the problem they're solving for users. Netflix's encoding pipeline justifies custom technology because video quality at scale is the product. Amazon's service architecture makes sense because they have thousands of engineers who need to move independently to solve different user problems.
But most products aren't LinkedIn, Netflix, or Amazon. Most products are tools that help people get work done, and those products win by solving user problems reliably and completely, not by having interesting infrastructure.
If you're going to innovate, innovate where users can see it. Build the feature that competitors can't copy. Solve the problem your customers actually have. Use boring technology for everything else, because the technology itself isn't the product—the solution is.
The Compound Effect
Technology choices compound over time. A boring stack today means faster hiring next year because candidates already know your tools. Fewer maintenance surprises the year after because the bugs have been found and fixed. When you need to scale, you have a wealth of resources showing exactly how others did it at your scale.
The exciting stack creates debt that accumulates. Every update requires investigation because the changelog assumes deep context. Every hire requires training because the tools aren't standard. Every integration requires custom work because the ecosystem hasn't caught up. The debt accumulates until someone finally proposes a rewrite, which starts the cycle over.
GitLab documented this explicitly. They chose Rails not because it was exciting, but because it was boring enough that contributors could focus on GitLab's differentiators instead of learning a bespoke framework. That's the goal: pick technology so boring that your team forgets about it and focuses on the problems you're solving. That's when you win.
Try This
List every technology in your current stack. For each one, write down when you adopted it, what specific problem it solved, whether that problem still exists, and how many people on your team understand it.
If you have technology that's been there more than a year, solves a problem you still have, and most of your team understands it—keep it. Everything else is a candidate for replacement with something boring.