Your tech stack is one of the few early decisions that's genuinely expensive to change. Pick well and you can grow for years on the same foundation. Pick on hype, or on whatever your first freelancer happened to know, and you may be paying for a migration just as the business takes off.
The good news: for most products, the right answer is boring.
What actually matters in a stack decision
Forget benchmarks and Twitter debates. These are the questions that decide whether a stack serves your business:
- Hiring. Can you find, afford and replace developers who know it? Popular, well-documented tools win here.
- Ecosystem. Are there mature libraries for payments, auth, email, PDFs, AI and the integrations your industry needs?
- Fit for the workload. A content site, a real-time chat app, a data pipeline and a mobile app have different needs.
- Operational cost. What does hosting cost at your current size, and at 10x?
- Longevity. Is it maintained by a stable company or community, with a track record of sane upgrades?
- Lock-in. If a vendor raises prices or shuts down, how hard is it to leave?
A sensible default for most products
For a typical SaaS, marketplace or internal tool, this combination covers the vast majority of needs with a large hiring pool behind it:
- TypeScript everywhere. One language across frontend and backend means shared types, fewer bugs at the boundaries, and a larger pool of developers.
- Next.js for the web app. Server rendering for SEO, API routes for simple backends, and first-class hosting on Vercel.
- React Native (with Expo) for mobile, when you need iOS and Android apps, sharing logic and much of your team's knowledge with the web app.
- PostgreSQL as the database. Relational, reliable and flexible: JSON columns, full-text search and vector search (pgvector) for AI features, all in one place.
- A dedicated backend (such as NestJS) when the domain grows: complex business rules, many integrations, background job queues with BullMQ, or multiple clients sharing one API.
- Managed services for the undifferentiated parts: Stripe for payments, a hosted auth provider, an email API, object storage like S3.
- A headless CMS such as Sanity for marketing pages and blog content, so non-developers can publish without a deploy.
When to choose something else
Defaults are a starting point, not a rule:
- Heavy data processing or ML training often fits Python better, as a separate service alongside the main app.
- Long-running jobs, websockets or persistent workers may outgrow serverless functions. Platforms like Railway, Fly.io or containers on AWS fit those workloads better.
- Strict compliance requirements (healthcare, finance, government) can dictate where data lives and which providers you're allowed to use.
- An existing team with deep expertise in another mature stack is usually a better bet than switching for fashion.
Red flags in a stack proposal
- A framework or database that's months old, with a small community, chosen because it's exciting.
- Microservices for a product with no users yet.
- A no-code or AI-builder platform you can't export clean, runnable code from.
- Several overlapping tools for the same job, which usually means nobody made a decision.
- No answer to "how do we run this locally, test it and deploy it?"
The bottom line
Choose boring, popular, well-supported tools for the core, and spend your novelty budget on the part of the product that actually differentiates your business. A good engineer's job isn't to pick the trendiest stack. It's to pick the one you won't have to think about for the next five years.
- CASE NOTES
