Best stack for shipping a SaaS in 2026

Stack debates are mostly identity politics. The honest answer for most SaaS products in 2026 is the same as in 2024, a tiny refresh of versions, the same overall shape. Below is the stack we recommend by default, and where the genuine alternatives earn their slot.

The default stack and why

• Frontend framework: Next.js 16 + React 19. App Router, Server Components, the metadata API for SEO, and the largest deploy-platform ecosystem of any React framework. The "what about Remix" question is real but secondary, covered in our Next.js vs Remix post.
• Styling: Tailwind v4. The CSS-first config and the smaller runtime make the v3-to-v4 migration worth it. The component library question (shadcn vs paid kits vs roll-your-own) is independent, Tailwind is the substrate.
• Language: TypeScript strict. Non-negotiable for a SaaS. The type system pays for itself the first time someone refactors a database column.
• Database: Postgres. Supabase if you want managed auth + RLS + realtime in the same product. Neon if you want serverless Postgres with branching. Either works. The thing that does not work is starting on a NoSQL database and migrating later, the schema you grow into is relational.
• Auth: Supabase Auth, Clerk, or a small custom layer. Supabase if you are already on Supabase. Clerk if you want the most polished hosted auth UI. Custom only if you have a specific compliance or shape requirement.
• Billing: Stripe direct, or Polar / Paddle / Lemon Squeezy as merchant of record. Stripe for control, MoR for EU VAT and chargeback handling on digital goods sold worldwide.
• Email: Resend. React Email components, decent deliverability, the API is small enough to learn in an hour.
• Hosting: Vercel for Next.js, or a Docker image on Fly/Railway/Render. Vercel for the path of least resistance. Docker for the team that has a strong reason to self-host.
• Observability: Sentry + a simple analytics layer. Sentry for errors, PostHog or Plausible for product/page analytics. Bigger setups (DataDog, Grafana) are premature for a pre-PMF SaaS.

The full version of this list, with the exact dependency versions and the trade-offs at each layer, lives at /stack.

Where to deviate

A stack should be defended, not defended for its own sake. Three deviations that earn their slot:

1. Multi-tenant B2B with strict isolation needs. The Postgres + RLS pattern is non-negotiable. Pick a hosting provider that gives you a connection pool and migration tooling that respects RLS. The full multi-tenant primitives, workspaces, RBAC, RLS policies, 2FA, audit, ship in /saasforge-core.
2. AI products with RAG. Add pgvector (already in Supabase Postgres) and a streaming chat layer using the Vercel AI SDK. Models worth supporting in mid-2026 are claude-opus-4-7, claude-sonnet-4-6, and OpenAI's current GPT line (verify in current docs, model names move). /saasforge-ai wires this end-to-end with credit metering.
3. Real-time collaboration. Liveblocks or a self-hosted Yjs setup. This is the only case where "Next.js is enough" runs out of road quickly, the moment two users edit the same document, you need a CRDT or operational transform layer.

What to ignore

A short list of stack decisions that do not matter as much as the discourse implies:

• ORM choice. Prisma, Drizzle, raw SQL, pick one, do not relitigate it after week two.
• Component library brand. Whatever you can read and modify works.
• Monorepo vs single repo. Single repo until you have a reason, usually mobile or a separate marketing site.
• React Server Components vs everything-client. RSC by default in App Router, drop into client components when you need interactivity. The "everything-client" reflex from older React is a habit, not a requirement.

The point of a stack decision is to spend the next eighteen months building product, not relitigating the foundation. Whichever stack you pick, pick once and start shipping.