Every early-stage build has a moment where someone proposes the new database, the new framework, the new runtime that solves problems the team doesn't have yet. It's rarely dishonest — it usually comes from genuine excitement, or from a blog post that made a hard problem look solved. But at the stage where the real question is still 'does anyone want this,' every unfamiliar dependency is a small, compounding tax paid in production incidents nobody has debugged before.
Dan McKinley's well-known 'choose boring technology' framing puts a number on this instinct: your team has a limited supply of what he calls innovation tokens, and every genuinely novel technical choice spends one. Spend them on the one or two things that are actually your product's differentiator. Everything else — the database, the queue, the deploy pipeline — should be the option your team already has scar tissue with.
This isn't an argument against learning new tools. It's an argument about sequencing. The two hardest problems for an early product are finding out whether it's wanted and finding out whether it can be operated by the people who'll actually be on call for it. Novel technology makes both harder at exactly the moment the team can least afford it.
We see the pattern most clearly with clients who arrive having already picked a stack for reasons that had nothing to do with the problem — a framework someone wanted on their résumé, a database chosen because it was trending. None of it is unusable. Most of it just adds a debugging tax to every incident, paid in unfamiliarity instead of money.
Our default with early-stage builds is boring on purpose: a proven language, a database with twenty years of documented failure modes, a deploy process that doesn't require reading anything new. If the product finds traction and a specific bottleneck shows up that boring technology genuinely can't solve, that's the signal to spend an innovation token — not a hunch, not a trend, a bottleneck you can name.