The tech stack question comes up early for almost every founder, and it usually gets answered the wrong way: by picking whatever the loudest blog post that week says is “the future,” rather than what the actual product needs.
Start with the constraints, not the trends
Three things decide a stack more than any framework comparison: how fast you need to ship a first version, how big the team building it actually is, and what happens after launch when you need to hire more developers. A single founder with no engineering background needs something different from a team of five experienced engineers — and both are different again from a team that expects to scale to fifty.
Boring technology is usually the right call
A mature, well-documented stack with a large hiring pool (Laravel, Rails, Django, a standard React/Node combination) will almost always beat something newer and more exciting for a first product. The interesting technical problems come later, once you actually have users. Before that, the only job of the stack is to not get in your way.
What actually matters for a v1
- How quickly can a new developer become productive in it
- Whether hosting and deployment are simple enough that your team isn’t also becoming a part-time DevOps shop
- Whether the ecosystem has solved the boring problems — auth, payments, admin panels — so you’re not rebuilding them
The stack you pick for a first product rarely survives unchanged to year three anyway. Pick something that lets you learn what the product actually needs to be, and plan to make real architecture decisions once you know that.