The Case for Boring Tech in Client Projects
Every few months something new appears in the frontend ecosystem and gets very loud very fast. A new framework, a new bundler, a new state management library that finally solves the problem the previous one created. The community benchmarks it, writes about it, builds demos with it.
I watch this happen and almost always use something boring instead.
What boring tech actually costs
Boring tech has a real cost. You don't get the new features. The ecosystem is older. Some patterns are more verbose than they'd be in the newer alternative. Developers who want to work with cutting-edge tools might find it less interesting.
Those costs are real. I'm not pretending otherwise.
What new tech actually costs
New tech has costs that are less visible upfront and more expensive later.
Documentation is thinner, because most of it is the README and a few blog posts from the launch week. Edge cases aren't covered. The answers you need haven't been written yet.
The API changes. Version 0.x → 1.0 breaks something. The migration guide has gaps. You spend a day on a problem that wouldn't have existed if you'd shipped on stable ground.
The community is smaller. When you hit a weird bug, fewer people have hit it before you. You're debugging in the dark.
For personal projects and experiments, these costs are acceptable. That's exactly what personal projects are for. You're learning, the consequences of a bad choice are low, and if it breaks you've learned something.
For client projects — where someone is paying for reliability, where production bugs cost them money, where the codebase will be maintained by people who didn't choose the stack — the calculus is different.
The specific calculus for client work
When I choose tech for a client project, I'm making a decision they'll live with for years, often after my involvement ends. The thing they care about is: does it work, does it keep working, and can someone else understand it?
Boring tech answers all three confidently. React + TypeScript + a stable styling solution is a stack that any frontend developer can pick up, that has answers for every problem on Stack Overflow, and that won't require a migration in two years because the project stalled on an abandoned library.
The new framework might be faster to write in for me, today. That benefit lasts for the initial build. The stability benefit lasts for the lifetime of the project.
When new tech earns its place
Not never. There are cases where a new technology provides something genuinely irreplaceable — a capability the stable alternatives don't have — and the project specifically needs that capability.
But that bar should be high for client work. "It's more fun" doesn't clear the bar. "It's slightly more ergonomic" doesn't clear the bar. "It does something we actually need that nothing else does" clears the bar.
The discipline is being honest about which situation you're actually in.
The real reason developers reach for new things
There's an honest reason developers want to use new technology on client work: it's more interesting. The boring stack is comfortable, and comfortable is boring after a while. New things are stimulating.
That's a legitimate feeling. It's not a good enough reason to put a client's production system on an unstable dependency.
The place to scratch that itch is on your own projects, your own time. You learn it there, you evaluate it honestly, and if it earns a place in client work, you bring it in on the next appropriate project — when it's stable enough.