Stack decisions made early should optimize for how cheaply you can change your mind, because at this stage you will change your mind.
1Optimize for the Uncertainty You Actually Have
Early on, the biggest source of risk is usually 'we don't yet know exactly what to build,' not 'this stack won't scale.' Choosing tools that minimize the cost of being wrong about product direction — not the ones that maximize theoretical scale — is the correct optimization at this stage.
2These Are Starting Defaults, Not Permanent Rules
Boring tech and a monolith are defaults for the uncertain, early stage — not a claim that they're always correct. As a product's shape solidifies and specific scaling or team-coordination pain shows up for real, reconsider each decision against the new, more certain information you now have.
3Step-by-Step Breakdown
'What's the best tech stack' is the wrong question early on. The right question is 'which stack lets us cheaply change direction once we learn we're wrong' — because at this stage, being wrong about some part of the product is the expected, not exceptional, outcome.
Favoring boring, well-understood technology (a mainstream framework, a standard relational database) over novel or exotic choices isn't a lack of ambition — it's a speed decision. Boring tech has more existing solutions to your problems already written down, so you spend less time debugging the tool itself.
Why does 'choose boring technology' make sense specifically for a product still iterating on what to build?
- →Because boring technology is always objectively faster at runtime
- →Because well-understood tools have more existing solutions and fewer unknowns, so less time is spent debugging the tool itself instead of iterating on the product
- →Because novel technology is always more expensive to license
- →It doesn't make sense — always choose the newest available technology
A single, simple deployable (a monolith) is usually faster to iterate on early than a microservices architecture, because changing behavior that spans multiple concerns doesn't require coordinating changes across separate services. Split into services later, once you actually know where the real boundaries are — splitting early usually guesses wrong.
Why does starting with a monolith usually beat starting with microservices for a product still figuring out what to build?
- →Monoliths are always faster at runtime than microservices
- →A monolith lets you change behavior spanning multiple concerns in one place, while an early microservices split usually guesses the wrong boundaries and adds coordination overhead
- →Microservices are illegal for small teams
- →There's no difference, the choice is purely stylistic
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Boring, Mainstream UI Frameworks Usually Have Better Accessibility Defaults
A well-established, widely used component library or framework has typically had far more real-world accessibility issues found and fixed than a novel or niche one — 'boring technology' as a speed heuristic often pays an accessibility dividend too.
// A mainstream, widely-used component library has likely already fixed
// common ARIA/focus bugs that a brand-new library hasn't discovered yetSEO Implications
- 1
Target 'how to choose a tech stack for an early-stage product' with a decision criterion, not a technology list
Readers researching this want the reasoning (optimize for change, not scale) rather than a specific opinionated list of frameworks that goes stale quickly.
Best Practices
Ask 'What Would Make Us Regret This Choice in 3 Months' Before Committing
For any non-trivial stack decision, explicitly imagine the scenario where it turns out wrong — usually it's 'we learned the product needed to do X, and this choice makes X expensive.' If that scenario feels plausible and costly, favor the more flexible, boring option.
Frequent Bugs
Splitting a product into microservices or picking a novel, unfamiliar technology early because it seems more 'correct' or impressive, before product-market fit is established.
Default to a monolith and well-understood technology until a specific, real pain point (not a hypothetical future one) justifies the added complexity — let actual evidence, not anticipation, drive the split.
Real-World Examples
The Premature Microservices Split
A 4-person team split their new product into 6 microservices from day one, anticipating future scale. Every product pivot over the next few months required coordinated changes across 3-4 services, dramatically slowing iteration — they eventually merged back into a monolith once the pain became undeniable.
// 6 months, 6 services, coordinated deploys for every product change
// vs. a monolith: change one thing, deploy once