In Praise of Boring Technology Choices

Every few months a new framework lands with enough momentum to make me wonder if I'm falling behind. The release notes are compelling. The benchmarks look clean. The demo is elegant. And somewhere in the back of my head, a voice starts asking whether the thing I'd normally reach for is showing its age.

I've learned to recognize that voice. It's not usually right.

The familiarity tax

When you pick up an unfamiliar tool, you're paying a hidden tax on everything you do with it. You don't know which parts of the documentation are accurate and which reflect an earlier version. You don't know which patterns the community has quietly abandoned. You don't know where the sharp edges are until you've already cut yourself.

None of that is a permanent cost — familiarity accumulates — but it's real, and it compounds. Every bug you hit becomes a two-part problem: is this my logic or is this the framework? Every error message is a new vocabulary to decode. The debugging loop slows down in ways that are hard to measure but easy to feel.

With boring technology, you've already paid that tax. The error messages are familiar. The Stack Overflow threads are five years deep. The AI-assisted suggestions are accurate because the training data is dense. You know where the sharp edges are, so you don't bleed on them.

What boring actually looks like in practice

When I built Composer Catalog — a SaaS platform for music composers — I made a series of choices that an enthusiast might charitably describe as conservative. Next.js. PostgreSQL via Prisma. Stripe for payments. S3 for storage. Clerk for auth.

None of those are new. None of them would generate a conference talk. But together they formed a stack where almost every problem I encountered had been solved before, documented clearly, and indexed somewhere I could find it at 11pm.

The interesting parts of that project — the waveform audio player, the playlist management system, the pitching workflow — demanded full creative attention. The infrastructure didn't. That's exactly how it should work. You want creative tension to live in the product decisions, not in figuring out why your ORM is generating unexpected joins.

The same principle held when I added a waveform player component using wavesurfer.js. Not a cutting-edge choice — wavesurfer has been around for years, v7 is mature, the community is large. The integration took a morning. A newer, less-adopted audio visualization library would have been faster to demo and slower to ship.

The signaling problem

There's a social dimension to technology choices that most practitioners are reluctant to name. Picking something new signals that you're paying attention, that you're forward-thinking, that you're not the person who's still using something from five years ago.

I understand the instinct. But the signal cuts both ways.

Reaching for the new thing without a clear reason tells experienced engineers something too: that you optimize for novelty over reliability, that you might introduce risk where none was necessary, that your judgment about what matters in a production system is still developing.

Choosing boring technology is its own kind of competence signal. It says you've thought about the tradeoffs and decided that your job is to ship working software, not to satisfy your own curiosity on a client's time.

When new technology actually earns its place

I want to be honest about when this calculus changes, because the answer isn't never.

New technology earns its place when the boring alternative genuinely can't do the job — not when it's inconvenient or unfamiliar, but when it structurally cannot deliver what you need. A graphics requirement that needs WebGL. An audio processing constraint that rules out standard browser APIs. A performance profile that can't be achieved within the limits of an older approach.

It also earns its place when you have genuine runway to learn: a personal project, a research spike, a side build where you're the only person affected by the cost. I've spent real time getting comfortable with tools on my own site — Framer Motion, Three.js for the hero mesh — specifically because the production blast radius was zero and the learning was worth having.

The mistake is importing that logic into client work, where the clock is running and the trust is finite.

The reframe that actually helped

The mental model I keep coming back to is this: technology choices are infrastructure decisions, and good infrastructure is invisible. When you're deep in a hard product problem, the last thing you want is your stack asserting itself. You want it to recede into the background and let you think.

Boring technology recedes. Unfamiliar technology asserts.

That's not a permanent statement about any specific tool. Familiarity is earned over time, and today's exciting new thing eventually becomes tomorrow's default. But "eventually" is doing a lot of work in that sentence, and "eventually" doesn't ship.

The practical rule

When I'm evaluating a technology choice now, I ask one question before anything else: do I already understand this well enough that it won't slow me down when I hit a hard problem at a bad time?

If the answer is yes, that's a point in its favor that competes with every other criterion. Ecosystem maturity, documentation quality, community size, AI training density — these all follow from the same underlying reality. Boring technology has been used, debugged, written about, and thought through by more people over more time. That work is available to me for free.

The new thing might actually be better. But "better on paper" and "better in production" are different claims, and I've learned to be skeptical of the gap between them.

Ship the thing that ships.