05.05 · Concept
Choosing Boring Technology
Apply the innovation-token argument to your own stack and justify each place you spent one.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
Boring technology preserves engineering attention for the risks that actually matter to the product. Treat unfamiliar databases, runtimes, queues, frameworks and deployment platforms as spending from a limited novelty budget, then require a clear payoff for each choice that adds operational learning, incident risk or migration cost.
What this lesson answers
- how to choose boring technology for a stack
- when is new infrastructure worth the operational risk
- how do innovation tokens apply to deployment decisions
Notes
Choosing Boring Technology — Choosing boring technology exists to conserve scarce engineering attention for the few parts of a system that truly differentiate the product; without it, teams spend their innovation capacity debugging databases, queues, frameworks, and deploy paths instead of shipping user value.
Key Concepts: - Treat “innovation tokens” as a finite budget: if a team has risky choices available, spending them on a new database, new language, and new deployment platform leaves tokens for product-specific technical risk.
Common questions
- What does boring technology mean in a production stack?
- Boring technology means tools your team, market and operations ecosystem already understand well. It is not simply old software. A boring database, cache, proxy or platform has known failure modes, available operators, mature docs, managed offerings and monitoring support, so the team spends less time discovering basic production behaviour.
- How should a team decide where to use novel technology?
- Use novel technology where the expected product or operational gain clearly outweighs the cost of learning, incidents and future migration. The justification should name the specific workload or constraint that boring defaults cannot handle, not just preference, fashion or a desire to avoid understanding the standard tool.
- Why is adding several new tools at once risky?
- Each unfamiliar tool adds unknown failure modes, training needs and integration work. When a team changes the language, framework, datastore and deployment path together, debugging becomes harder because every layer is suspect. Keeping most layers conventional isolates the real experiment and makes production issues easier to reason about.