Every project gets a novelty budget: a finite amount of unfamiliarity the team can absorb before velocity collapses. The mistake is spending it on infrastructure instead of the product.
The failure mode is always the same and always sincere. A new project kicks off, energy is high, and someone proposes the interesting stack — the new framework, the new database, the deployment platform from the conference talk. Each choice is individually defensible. Together they guarantee that month three is spent debugging the plumbing instead of learning what users need.
Boring is a technical term
Boring doesn't mean bad, and it doesn't mean old. It means the failure modes are documented. When Postgres does something surprising, a decade of Stack Overflow answers is waiting. When the framework released eight months ago does something surprising, you're reading its source at midnight — and you budgeted zero hours for that.
- Boring tools have known failure modes; novel tools have undiscovered ones
- Boring tools let new teammates contribute in days, not weeks
- Boring tools make your bugs your fault — which means fixable
Where to spend instead
The point of a boring foundation is to make room for ambition where users can feel it. Spend the novelty budget on the interaction that has no established pattern, the visualization nobody's built, the feature that justifies the product's existence. That's the work that deserves your midnight source-reading.
Innovate in the product. Standardize in the plumbing. Never both, never neither.
The portfolios I admire most are full of interesting work shipped on aggressively conventional stacks. The correlation isn't an accident — it's the budget, spent well.