Every project comes with a fixed novelty budget. You can spend it on the database, the deployment story, the framework, the language — or on the thing you're actually being paid to build. Spend it on the product.
Boring stacks win
tl:dr — Pick the technology that fails in ways you already know how to fix. Save your novelty budget for the actual product.
// what 'boring' actually means
Boring isn't a synonym for old. It means: well-documented, predictable failure modes, a large pool of engineers who've already debugged this exact stack trace at 2am. Postgres is boring. A server-rendered framework is boring. Object storage behind a CDN is boring. When something breaks in a boring stack, the first Google result is almost always the answer. When something breaks in a novel stack, you're the first Google result — and you have to write it yourself, while production is on fire.
// my default
$ ls ~/default-stackPostgres/ # the database, alwaysNext.js/ # or TanStack StartTailwind/ # stylingResend/ # transactional emailStripe/ # paymentsCloudflare/ # CDN + edge functions
I deviate from this only when there's a concrete reason — a workload that genuinely needs a different shape, not because something new showed up on Hacker News last week.
// when to break the rule
Boring stacks lose when the product itself is the novelty: realtime collaborative editing, ML inference at the edge, anything with hard latency budgets. Then the interesting tech is the point. Everywhere else, boring wins on every axis that matters once a project is older than six months.
Choose boring technology. — Dan McKinley
The best compliment a stack can get is that nobody ever has to talk about it.