Picking a Tech Stack That Outlives the Trend Cycle
Every few months a new framework promises to make the last one look naive. Most clients who ask us "what should we build this on" are really asking a different question: how do we avoid rebuilding this in eighteen months?
Most stack decisions are really risk decisions
A framework choice isn't primarily a technical bet — it's a bet on which risks you're willing to carry. Picking something brand-new trades a slower, more uncertain present (thin docs, a smaller hiring pool, rough edges nobody's filed issues for yet) for a faster theoretical future. Picking something mature trades a bit of today's elegance for a much larger margin of safety later.
What we actually weigh
- Can we hire for this in the market the client is actually hiring in, not just in our own team
- Does the ecosystem have more than one maintainer who could plausibly keep it alive for five years
- What does debugging a production incident at 2am look like — is there a community, real docs, and a paper trail of other people's war stories
- How much of the "exciting" part of this framework is actually load-bearing for this product, versus just exciting
The quiet cost of being first
Being an early adopter means every bug you hit is new. There's no Stack Overflow answer, no GitHub issue with a workaround, no blog post from someone who hit it eighteen months before you. That cost doesn't show up in a feature comparison table, but it shows up in every sprint for the life of the project.
The best engineers we work with are rarely excited about their stack. They're excited about what they shipped with it.
Boring is a feature, not a compromise
A "boring" stack — widely adopted, well-documented, with a deep hiring pool — isn't a lack of ambition. It's where we spend our ambition on the product instead of on the plumbing underneath it. That's almost always the better trade for a company that needs to still be shipping in three years, not just impressing other engineers this quarter.
