The B2B SaaS stack hasn't changed dramatically since 2023, but the consensus around the right defaults has. Below is what we ship for new B2B SaaS clients in 2026, with the reasoning. None of it is novel. All of it is boring on purpose.
Frontend: Next.js + TypeScript
The default. Next.js 15-16 with the App Router, React Server Components by default, TypeScript strict.
Why: largest ecosystem, deepest pool of senior engineers, best Vercel deployment story, and the only framework whose roadmap is anchored to React's. Remix is technically clean; the gravity is now in Next.js.
We avoid: SvelteKit (smaller hiring pool), Astro (great for content sites, not for apps), pure CSR with Vite (you'll regret it at scale).
Backend: Node + tRPC or REST
Default: same Next.js codebase serves the API. tRPC for internal-only APIs (typed end-to-end, fast iteration). REST for any API you'll expose externally to partners or third parties.
We avoid: GraphQL for early-stage SaaS unless you have a real reason. The schema complexity rarely pays back before $10M ARR.
Database: Postgres
Boring works. We default to Postgres on Supabase or Neon for early stage; Aurora or RDS at scale.
ORM: Drizzle over Prisma in 2026. Prisma still works; Drizzle's migrations and type safety are slightly better and the ecosystem has caught up.
We avoid: MongoDB for relational data (you'll regret it), DynamoDB unless you have a specific scaling reason, MySQL when Postgres is right there.
Auth: Clerk or WorkOS
Clerk for B2B SaaS targeting SMB/mid-market. WorkOS for B2B SaaS targeting enterprise (SSO, SAML, SCIM).
We do not roll our own auth in 2026. The total cost of ownership over 3 years is higher than any auth-as-a-service bill, and the security risk is real.
Billing: Stripe
Default. Period.
For subscription billing specifically, Stripe Billing has caught up to its smaller competitors and is the right choice unless you specifically need a Merchant of Record (Paddle) for tax compliance across many jurisdictions.
Email & transactional
- Transactional email: Resend or Postmark. Both are good; Resend's dev ergonomics are slightly better.
- Marketing email: HubSpot if you'll run a real marketing motion, Customer.io if you'll run cohort-based campaigns, Loops for early stage.
Observability
- Error tracking: Sentry. Default.
- Logs + traces: Axiom or Datadog. Axiom is cheaper for early stage; Datadog wins at scale.
- Feature flags: PostHog or LaunchDarkly. PostHog if you also want product analytics; LaunchDarkly if you want best-in-class flags.
Background jobs
Inngest or Trigger.dev. Both are fine. Inngest's developer experience is slightly better; Trigger has better long-running task support.
We avoid: rolling your own queue with BullMQ unless you have specific reasons (cost, control). The TCO of a managed solution is lower for almost all teams under $20M ARR.
Deployment
- Frontend + serverless backend: Vercel until cost forces you off
- Heavy backend / always-on workloads: Hetzner with Coolify, AWS Fargate, or Fly.io
- Database: Supabase / Neon for early stage; AWS RDS / Aurora at scale
The honest answer: deployment cost rarely matters at early stage. Once you're past $5M ARR, the math on managed vs self-hosted starts shifting. We typically don't recommend leaving Vercel until you have a specific cost or feature reason.
CI / CD
GitHub Actions. Boring, mature, well-documented.
Analytics
- Product analytics: PostHog (open-source friendly, generous free tier) or Mixpanel (cleaner UI)
- Web analytics: GA4 + Vercel Analytics or Plausible
CRM + sales
- HubSpot for B2B SaaS doing inbound + outbound. Best CRM under $10M ARR.
- Salesforce for $10M+ ARR with serious sales motion. More expensive, more customizable, less ergonomic.
What we don't bother with at early stage
- Custom DevOps. Use Vercel + managed Postgres.
- Custom CMS. Use Sanity or Contentful, or MDX-on-GitHub if your editors are technical.
- Custom analytics. Use PostHog or Mixpanel.
- Custom auth. Use Clerk or WorkOS.
Build what's differentiated. Buy what isn't.
The 5 stack mistakes we see most often
- Choosing Mongo / DynamoDB / a graph DB when Postgres would do. Postgres covers 95% of B2B SaaS workloads. Choosing something exotic adds operational burden and hiring difficulty.
- Building auth from scratch. It's slower than you think and the security blast radius is bigger than you think.
- Going headless commerce at $1M ARR. Premature. Stay on Stripe + your app's native pages.
- Adopting GraphQL before you need it. Schema complexity ahead of customer count.
- Picking a niche framework because it's cool. The hiring pool 18 months from now matters more than the dev ergonomics today.
The first-90-days build sequence we ship
This is the sequence we'd ship at our Full-Stack Software practice for a Series A B2B SaaS:
- Week 1-2: Discovery + architecture spike. Schema, API contract, deployment topology written down.
- Week 3-4: Auth, billing, base admin dashboard. The boring infrastructure layer.
- Week 5-7: Core feature one, the value-prop-delivering surface.
- Week 8-10: Core feature two + integrations.
- Week 11-12: Onboarding flow + observability stack.
- Week 13-14: QA + first design partner deployments.
By week 14 you have something a paying customer can use. By week 20 you have something worth selling.
Read next: