How I choose technologies (and when I refuse the shiny option)

Every year there is a new default answer. Last year it was one framework. This year it is another. The teams that stay sane are not the ones who chase every announcement, they are the ones who can explain why a choice fits this product, this team, and this stage.

My shortlist questions

• Can we hire and onboard for this in the next six months?
• Does it reduce operational risk, or only developer dopamine?
• What breaks at 10x traffic or 10x features, and can we see that early?
• Is the ecosystem boring in a good way (docs, libraries, battle scars)?
• If I leave, can someone else maintain this without archaeology?

I lean TypeScript across the stack when I can, React and Next.js on the web, NestJS for APIs, React Native when mobile must share product language with the web. Not because they are trendy, but because shared types and patterns cut coordination cost when one engineer wears many hats.

Saying no is a skill

I have sat in rooms where the proposal was a rewrite for aesthetics. Greenfield energy feels productive. It often destroys momentum. Choosing technology well means protecting the product’s runway: pick tools you can operate at 2 a.m., not tools that look clever in a slide deck.

The stack should disappear into the work. If you spend more time debating libraries than shipping outcomes, the technology already chose you.