Why I Choose Boring Technology #
There’s a new JavaScript framework every week. A database that promises to solve all your problems. A deployment platform that makes everything “just work.”
I don’t use most of them.
Instead, I build with proven, boring technology. Not because I’m conservative. Not because I don’t like learning new things. But because boring technology lets me focus on actual problems instead of tooling problems.
What “Boring” Means #
Boring doesn’t mean old. It means:
- Documented extensively. When you hit a problem, someone else hit it five years ago and wrote about it.
- Deployed at scale. The edge cases are known. The failure modes are understood.
- Stable APIs. Your code from 2020 still works in 2024.
Postgres is boring. React is becoming boring. Docker is boring. These tools aren’t exciting, but they’re predictable.
The Hidden Cost of Novel Technology #
New tech comes with hidden costs:
- Learning curve. Not just for you—for everyone who touches the code.
- Immature tooling. No debuggers, no profilers, no battle-tested libraries.
- Breaking changes. That major version bump that rewrites everything you built.
- Limited knowledge pool. When you’re stuck, Stack Overflow has 3 answers, all from the framework author.
I’m not saying never use new tech. I’m saying understand the cost. If you’re betting your product on a framework with 1,000 GitHub stars and one maintainer, you better have a good reason.
Where I Spend My Innovation Budget #
Here’s my rule: be boring in infrastructure, creative in product.
Use Postgres instead of that new vector database. Use React instead of the framework-of-the-week. Use Git instead of whatever “Git alternative” is trending.
Then spend your innovation budget on solving user problems, not tooling problems.
Real Examples from My Work #
Task Orchestrator #
I built a distributed task queue that processes 100K+ jobs daily. The stack?
- Node.js (boring)
- PostgreSQL (boring)
- Redis (boring)
- Docker (boring)
Nothing novel. Nothing exciting. But it works. It scales. It’s maintainable. When something breaks, I can find solutions.
Design System #
Production-ready component library with 24+ components. The stack?
- React (boring)
- TypeScript (boring)
- Storybook (boring)
I could have used a newer framework. I could have written it in a compile-to-JS language. Instead, I used tools that millions of developers already know, making the system accessible to more teams.
When to Use Exciting Technology #
Here’s when I consider new tech:
-
The boring solution fundamentally can’t solve your problem. Not “it’s slower” or “requires more code.” I mean truly, architecturally impossible.
-
You have the resources to maintain it. Can you fix bugs in the framework yourself? Can you hire people who know it? Can you migrate away if it dies?
-
The problem is in your domain, not infrastructure. Building a novel database? Use novel tech. Building a CRUD app? Don’t.
The Paradox of Constraints #
Here’s what surprised me: boring technology makes you more creative.
When you can’t reach for the shiny new framework that “solves everything,” you have to actually understand the problem. You have to think. You have to design.
Constraints breed creativity. Boring tech is a constraint.
My Current Stack #
For 90% of projects, I reach for:
Frontend:
- React
- TypeScript
- Astro (for static sites)
- Tailwind CSS
Backend:
- Node.js
- PostgreSQL
- Redis
- Docker
Deployment:
- GitHub Actions
- Vercel (for static sites)
- Docker Compose (for everything else)
This stack is boring. It’s also battle-tested, well-documented, and proven at scale.
The Bottom Line #
Use boring technology. Solve interesting problems.
Your users don’t care that you rewrote everything in the hot new framework. They care that the app works, performs well, and doesn’t break on updates.
Boring technology gives you that. Exciting technology gives you Hacker News points.
Choose wisely.
Further Reading: