The decision founders overestimate and CTOs underestimate
When a founder asks me what stack they should use for their product, the answer they want to hear is a concrete list: "use this for the frontend, this for the backend, this for the database." And I can give them that. But before getting to that list, there's a more important conversation to have.
The tech stack isn't what determines whether a product succeeds or fails. What determines success is how quickly you can find a real problem, build something that solves it, and reach the right people before you run out of runway.
I've seen startups with brilliant architectures that never found a customer. And I've seen products built on WordPress that do seven figures. The stack choice matters, but it matters within a reasonable range — and that range is wider than most people think.
That said: within that reasonable range, some choices are clearly better than others depending on context. And making the wrong choice doesn't kill the product, but it can make it significantly more expensive to maintain and scale. That's what I'm going to break down in this article.
The most expensive mistake: choosing a stack for the wrong reasons
There are three bad reasons to choose a stack, and all three are more common than they should be:
"It's what I know best." If the technical team only knows PHP, building the backend in PHP is pragmatic. But if that choice slows down hiring, makes integration with the modern tooling ecosystem difficult, and generates technical debt that will be expensive to pay off in 18 months, the cost of learning something new now is lower than the cost of migrating later.
"It's what [big company I admire] uses." Uber uses Go. Airbnb uses React. Netflix uses Java. None of those choices were made for a 3-person team with 6 months of runway. The scale of those problems isn't yours. What works for millions of requests per second isn't necessarily right for getting to your first 1,000 users.
"It's the newest and most modern thing." Frontier technology has sparse documentation, small communities, and more unresolved bugs. For a team that needs to move fast, fighting the problems of an immature tool is a luxury you can't afford. Boring and proven usually wins.
The three questions that define the right stack
Before talking about specific technologies, I need answers to these three questions:
1. How uncertain is the shape of the product?
If you're still validating whether the product solves a real problem — if the business model isn't confirmed, if the main flow could still change radically — you need a stack that lets you iterate quickly even if it's technically imperfect. Speed of change matters more than architectural elegance.
If you already have validation and are in scale mode — predictable growth, well-defined engineering problems — you can afford more deliberate choices for the long term.
2. How many people are going to build this?
A one- or two-person team with full-stack capability needs a stack that minimizes the context to manage. Having frontend, backend, database, and infrastructure separated across 4 different languages is an enormous cognitive load for a small team.
An 8-person team with specialization can divide responsibilities and optimize each layer independently. What's excessive for a small team may be necessary for a large one.
3. What type of technical problem is at the core of the product?
A management SaaS with tables, forms, and reports has very different requirements from a real-time video processing platform, a generative AI application, or a marketplace with complex matching logic. The right stack for one may be inadequate for the other.
The stack I recommend for most B2B SaaS in 2026
With all the above caveats clear, here's a combination that works for the majority of B2B SaaS projects that a small team is building today:
Frontend + Backend: Next.js with TypeScript
Next.js with the App Router is today the de facto standard for web products that need to be fast to build, good at SEO, and maintainable by small teams. The main reason isn't that it's the best framework in abstract technical terms — it's that it concentrates the largest ecosystem of components, documentation, solutions to common problems, and available developers in the market.
TypeScript over JavaScript is non-optional in 2026. The initial investment in types pays off handsomely in reduced production bugs and maintainability when someone new joins the project six months later.
For most SaaS products, Next.js as a monolith — frontend and API routes in the same repository — is sufficient up to the first 50,000 active users. You don't need microservices. You don't need to separate the backend into its own service. Adding infrastructure complexity before you need it is technical debt disguised as architecture.
Database: PostgreSQL
PostgreSQL is the most capable relational database that exists today and it's free. For 95% of SaaS products, a relational database with good data modeling is all you need. If at some point you need something that PostgreSQL can't do well, you'll know exactly why and you'll be in a position to evaluate it with real data, not speculation.
Provider choice depends on context:
- Supabase: the best option to start. Managed PostgreSQL + authentication + storage + real-time APIs. Reduces infrastructure work to zero initially and has a generous free tier.
- Neon: serverless PostgreSQL with database branching. Excellent for teams working with multiple environments who want costs proportional to actual usage.
- RDS / Cloud SQL: when you need enterprise SLAs and already have infrastructure on AWS or GCP.
MongoDB and other document databases are rarely the right choice for B2B SaaS. The schema flexibility they promise turns into data inconsistency and complex queries as soon as the product has more than 6 months in production.
Infrastructure: Vercel + Railway
For the Next.js frontend and API routes, Vercel is the obvious choice. Automatic deploy from Git, preview deployments for every pull request, global CDN, and zero configuration. Cost is reasonable up to mid-scale.
For independent backend services when you eventually need them — processing workers, scheduled jobs, integration services — Railway is the simplest option that exists today. A container with environment variables, no need to configure clusters or load balancers.
AWS and GCP make sense when you have a dedicated DevOps team or compliance requirements that force specific provider choices. For a 3-to-10-person team building a SaaS, AWS's operational complexity outweighs its advantages.
Authentication: Clerk or Auth.js
Authentication is a solved problem. Don't build it from scratch. Clerk has the best implementation experience on the market today — in 30 minutes you have email login, Google, magic links, and MFA working — and its pricing model is reasonable up to tens of thousands of users.
If you prefer something open source and self-hosted, Auth.js (formerly NextAuth) is the standard alternative for Next.js projects.
When this stack isn't the right one
There are cases where this recommendation doesn't apply:
If the product's core requires heavy data processing. ML analysis, image or video processing, high-volume data pipelines: Python is unbeatable for these tasks. A FastAPI backend for the ML logic, exposed as an API and consumed from Next.js, is a clean separation that makes sense.
If you need extremely low latency at massive scale. Go or Rust for performance-critical services. But this rarely applies before 100,000 concurrent users.
If the team already has deep expertise in another stack. A team of five expert Laravel developers can build a quality SaaS in PHP faster than the same team learning Next.js. The switching cost matters.
If there are compliance requirements that dictate infrastructure. HIPAA, SOC 2, or local regulations may force provider decisions regardless of what's technically optimal.
The over-engineering trap
The mistake I see most often in technical founders is designing the architecture for the problem they'll have in two years instead of the problem they have today.
Microservices for a product with 50 users. Event sourcing for a CRUD application. Kubernetes for a two-person team. Each of these decisions adds cognitive load, debugging time, and onboarding friction for new developers — in exchange for advantages that don't materialize until scale.
The rule I use: build the monolith until the pain of not having it separated is concrete and measurable. Not speculative. When a specific service needs to scale independently because the data confirms it, that's the moment to separate it. Not before.
Jeff Bezos described this idea as "two-way door decisions" vs. "one-way door decisions." Decisions that can be reversed at reasonable cost — adding a service, refactoring a module — don't deserve the same deliberation as those that are hard to undo, like changing the main database or migrating infrastructure providers.
The stack for products with AI components in 2026
If the product includes AI functionality — text generation, document analysis, agents, semantic search — there are additional layers to consider:
LLM as an external API: Anthropic, OpenAI, or Google. Don't train your own models unless you have a dedicated ML team and proprietary data that justifies the cost. Frontier model APIs are cheap at startup scale and constantly improving.
Vector database for semantic search: pgvector on top of PostgreSQL is sufficient for most cases up to millions of vectors. Pinecone or Weaviate if vector search volume is the core of the product.
Agent orchestration: n8n for automation workflows with LLMs. Vercel AI SDK if agents live directly in the Next.js application. LangGraph for complex stateful agent systems.
A simple heuristic for deciding
When someone presents a stack proposal to me and I'm not sure whether it's the right one, I ask one question: how long would it take a new developer, with two years of experience, to understand this system and make their first production deployment?
If the answer is more than a week, there's probably unnecessary complexity somewhere. The best systems I've seen in production are the ones a competent developer can fully understand in a day.
Complexity that you can't explain to someone in an hour is complexity you're going to pay for with debugging time, production bugs, and team friction for the next several years.
The stack is a decision, not an identity
The most frequent mistake I see in technology conversations — especially in developer communities — is treating the stack as an identity. "I'm a React person, not Vue." "I use Go, not Node." Those loyalties don't serve the product's objectives.
The right stack is the one that lets your specific team solve your customers' specific problems, with the speed that your business context requires, at the cost you can sustain. That changes over time, and changing tools when context justifies it isn't a sign of inconsistency — it's pragmatic engineering.
If you're evaluating your product's stack and want a second opinion, that's exactly the type of conversation I have in free diagnostics. Thirty minutes to review your context, your team, and your product, and give you a concrete recommendation with the reasoning behind it.