Every week we talk to a founder who is stuck. Not because their product idea is bad — but because the tech stack chosen 18 months ago is now fighting them at every turn. Deployments take hours. Adding a new developer costs weeks of onboarding. Simple features take sprints to ship.
It didn't have to be this way.
The mistake most teams make
The most common pattern we see: a startup's first engineer joins, picks the stack they know best, and ships fast. This is actually the right call — in the early days, speed of execution beats everything.
The problem is that nobody revisits the decision. The codebase grows. The team grows. And suddenly you are paying for technical choices made under completely different constraints.
A framework for picking a stack that lasts
When we advise founders on their stack, we think across four dimensions:
1. Talent availability
Can you hire for this? A brilliant stack nobody else knows is a single point of failure. Before committing to a technology, ask yourself: if your lead engineer quit tomorrow, how long would it take to replace them?
Practical rule: Prefer boring, popular technologies. Next.js, Node.js, PostgreSQL, and React have massive talent pools. Your exotic choice may be technically superior — but the hiring cost eats that advantage.
2. Operational complexity
How much of your time will go to keeping the lights on versus building product?
A common trap is choosing a microservices architecture before you have the team or traffic to justify it. Start with a well-structured monolith. You can always split it later — and you'll split it in the right places once you understand your actual load patterns.
3. Scalability ceiling
Where does this technology break down? You don't need to solve for 10 million users on day one. But you should not be choosing something that caps you at 10,000 either.
Good news: The right choices at the lower scale levels — PostgreSQL, proper indexing, server-side rendering, CDN caching — take you surprisingly far before you need anything exotic.
4. Ecosystem maturity
Are there libraries for the things you'll need? Auth, payments, email, file storage, queues — these are solved problems. Your tech stack should have mature, maintained solutions for all of them. If you find yourself writing infrastructure from scratch, that's a warning sign.
What we recommend for most startups
For 80% of the startups we talk to, this stack covers everything they need:
- Frontend: Next.js with TypeScript
- Styling: Tailwind CSS
- Database: PostgreSQL via Supabase (or a managed Postgres service)
- Auth: Supabase Auth or NextAuth
- Payments: Stripe
- Email: Resend
- Hosting: Vercel (frontend) + Supabase (backend/DB)
This is not exciting. It is deliberately boring. And boring is exactly what you want when your goal is to build a sustainable business — not win a hackathon.
When to deviate
There are legitimate reasons to go off the standard path:
- Real-time requirements at scale — WebSockets, edge computing, or specialised databases may make sense
- AI/ML at the core — Python becomes relevant if your product is fundamentally model-based
- Mobile-first — React Native keeps you in the JavaScript ecosystem while targeting both app stores
Even then: exhaust the boring option first. Real-time chat can be built on Supabase's realtime subscriptions before you need to engineer your own WebSocket layer.
The question to ask yourself
Before committing to a technology, ask: "In 18 months, will this choice make my life easier or harder?"
If you can't confidently answer "easier," spend another day researching. That day is cheap. Migrating a production system is not.
If you're early-stage and unsure about your stack choices, we offer free 30-minute technical consultations. No pitch — just honest advice. Book a call →