Which stack should you choose for a B2B SaaS in 2026?
Stack choice is 80% boring and 20% differential. Here is the default stack we recommend and where it makes sense to deviate.
"Which stack should we choose?" is founders' favorite question and teams' worst time investment. The reality is that for a B2B SaaS in 2026, there is a default answer that works for 90% of cases, and debating it for 3 months only delays the product. What is worth thinking about are the 4 decisions that actually move the needle.
The default stack (works for 9 out of 10 B2B SaaS products)
- Frontend: Next.js 15 (App Router) + React 19 + Tailwind CSS + shadcn/ui.
- Backend: Next.js API routes for 80% of endpoints; separate Node/Express service only for long jobs or WebSockets.
- Database: PostgreSQL on Supabase, Neon or RDS. ORM: Drizzle or Prisma.
- Auth: Clerk or Auth.js. Add enterprise SSO later with WorkOS.
- Billing: Stripe + Stripe Customer Portal.
- Email: transactional Resend + React Email for templates.
- Storage: S3 or R2.
- Background jobs: Inngest or Trigger.dev. Do not reinvent with BullMQ unless you already know it.
- Observability: Sentry + PostHog. Logs in Axiom or Better Stack.
- Hosting: Vercel + Supabase. For more control: Fly.io + Neon.
- CI/CD: GitHub Actions with tests + Vercel deploy preview per PR.
This stack lets a 2-4 person team build a commercial product in 4-6 months. Any senior React developer can ramp up in a week. Operating costs: US$80-300/month up to the first 5,000 users.
When to leave the default
- Your product has heavy compute (video processing, large ML inference, simulations). Add Modal or RunPod for that module, not for everything.
- You need strong bidirectional real-time (Figma-like collaboration, multiplayer). Add Liveblocks or Partykit.
- You operate in a jurisdiction that requires on-prem data. Self-hosted PostgreSQL + Hetzner/OVH/CloudSigma + Coolify or Dokku.
- Your team comes from Rails/Django/Laravel. Do not force them to migrate. Rails backend + Next.js frontend works perfectly.
The 4 decisions worth thinking about
1. Monolith or services
Modular monolith by default. Services only when there is a concrete reason: a large team stepping on the same repo (rare in MVPs), or a module with very different requirements (Node + Python ML, for example). Rule: start monolithic and decouple later when it hurts.
2. Multi-tenant strategy
Three options: one DB per tenant (expensive, simple), shared DB with tenant_id (default, enough for 95%), DB-per-region but shared inside (advanced). Default: shared with tenant_id and row-level security in Postgres. Document the policy and apply it in every query.
3. ORM vs query builder vs raw SQL
Drizzle is the 2026 sweet spot: type-safe, performant, lets you write SQL when needed. Prisma is still valid but TS-heavy and has a separate schema. Knex/raw SQL only if your team comes from that. Avoid ORMs that generate opaque automatic migrations.
4. Managed auth provider vs DIY
Clerk: 10x faster setup, US$25/month floor, stops making sense around 10k MAU (price scales). Auth.js: free, more setup work, you manage sessions. For B2B SaaS with enterprise SSO: Clerk + WorkOS is default. For intensive usage without SSO: Auth.js.
Hosting + DB comparison
| Hosting stack | Cost floor | DX | When to choose |
|---|---|---|---|
| Vercel + Supabase | US$25/month | Best on market | Default, 90% of cases |
| Vercel + Neon | US$20/month | Excellent | Alternate default if you want branching DB |
| Fly.io + Neon | US$20/month | Good | More runtime control, multi-region |
| AWS Fargate + RDS | US$120/month | Medium | When enterprise requires it for compliance |
| Hetzner + self-hosted | US$8/month | Low | Cost-conscious, someone has DevOps skills |
Anti-patterns that kill speed
- Microservices from day 0. Adds 30-60% complexity with no benefit before 50k users.
- Kubernetes for 5 users. Vercel/Fly.io is better until you have a real reason for K8s.
- GraphQL "because it sounds modern". REST + tRPC covers 95% of needs. GraphQL wins when many clients consume the same API with variable queries.
- Custom UI framework. Tailwind + shadcn/ui gives 90% of the value. Building your own design system before product is vanity.
- Server-side rendering everywhere. ISR + edge caching where there is no personalization. SSR only for pages with auth.
Typical speed to production with this stack
- Initial setup (auth + billing + base): 3-5 days.
- First core feature: 1-2 weeks.
- Defensible MVP: 8-12 weeks.
- Commercial product v1: 4-6 additional months.
Should I use Bun instead of Node?
In 2026 Bun is stable for new services, but Vercel still optimizes for Node. If you self-host on Fly.io, Bun gives 15-30% better performance. If you use Vercel, stay on Node.
What about Rust / Go for the backend?
Only if the real bottleneck is CPU/throughput and you already validated the model. For 99% of B2B SaaS products, Node + Postgres handles 100k+ users.
Do microservices help the team scale?
No. Code organization matters more than physical fragmentation. A well-built modular monolith (folders by domain, controlled dependencies) scales better than 12 poorly coordinated microservices.
What we recommend
If you are starting a new B2B SaaS in 2026: start with the default stack exactly as described. Do not debate for 2 months which ORM to choose; take Drizzle, write code, move. Details can change later; time lost in the initial decision never comes back.
If your team already has different expertise: respect that expertise. A team of 5 senior Rails developers will produce 3x faster in Rails + Next.js than in full-stack Next.js. The right discussion is not "which stack is better in abstract", but "which stack lets this team deliver faster without sacrificing maintainability".