How to Choose a Tech Stack for Your Startup

Founders spend weeks agonizing over tech stack decisions that rarely determine the outcome of their startup. The choice that actually matters — can you ship fast enough to learn what customers want — is almost never about the specific framework. It's about whether you can move without friction.

The popularity trap

A new framework reaches the front page of Hacker News every few weeks. Each one claims to solve problems you probably don't have yet. The cost of switching from an unfamiliar but popular framework is rarely worth the theoretical benefits. If your team knows React, use React. If they know Laravel, use Laravel. The framework will not be the reason your startup succeeds or fails.

What actually creates friction

• Building things that don't need to be built — custom authentication, custom admin panels, custom deployment pipelines. Use Auth.js, use a hosted admin panel, use Vercel or Railway.
• Premature optimization — a monolith with a single database is faster to build, easier to debug, and cheaper to run than a microservice architecture. You will know when you need microservices because you'll be paying someone to manage the complexity of your monolith.
• Tech that nobody on the team knows — the learning curve of a new language or framework is weeks or months of zero shipping velocity. Unless you have runway to burn, use what you know.

When to make an exception

There are good reasons to choose a specific stack — you need real-time features (choose something with WebSocket support), you're doing heavy ML work (Python ecosystem is hard to beat), or you're building for a platform that mandates a language (iOS development requires Swift). In every other case, the default answer is 'what can we ship fastest?'

I've built the same product twice for different clients — once in Next.js and once in Laravel. Both shipped, both scaled, both made money. The tech stack was never the constraint.