The Startup Stack in 2026 — What Indie Founders Are Actually Building With
Startup StackIndie HackersTech ChoicesB2B SaaSDeveloper Tooling

The Startup Stack in 2026 — What Indie Founders Are Actually Building With

T. Krause

A solo founder building a B2B SaaS in 2026 has a stack that didn't exist in 2024. The choices have converged enough to talk about a default — and the default is dramatically different from what JS bootcamps were teaching two years ago.

A friend who has been shipping indie SaaS projects since 2018 walked through his 2026 stack in May. His 2023 stack was Next.js plus Supabase plus Vercel plus a custom auth layer plus various integrations he'd cobbled together. His 2026 stack was tighter, more opinionated, and substantially more productive. The components had converged on a default that didn't exist two years ago.

For founders considering what to build with, the question has become easier than it was. The current defaults aren't quite the universal answer, but they're closer to "you should probably use this unless you have a reason not to" than the stack debates of 2022-2023 ever produced.

The Current Default Stack

Framework: Next.js with App Router on Vercel. Still dominant for B2B web SaaS. The integration with Vercel's deployment platform, the maturity of the App Router, and the strength of the surrounding ecosystem keep it at the center. Alternatives (Remix, SvelteKit, Astro) have niches but Next.js is the default.

Database: Postgres on a serverless platform (Neon, Supabase, or Vercel Postgres). The serverless Postgres options are mature enough that running your own database for a small SaaS is rarely the right choice. Neon's branch-per-PR model, Supabase's batteries-included approach, and Vercel Postgres' tight integration each have their adherents.

Auth: Clerk or NextAuth (Auth.js). Clerk has won the "I want to ship auth without thinking" category. NextAuth/Auth.js is the strong open-source alternative for teams that want more control or self-hosting.

Payments: Stripe with Stripe Tax. Still the default. Stripe Tax handles the EU VAT and US sales tax complexity that used to require separate accountants. For SaaS especially, the integration is straightforward.

Email: Resend (transactional) and Loops (lifecycle). Resend has taken the transactional email category. Loops has emerged as the lifecycle/marketing email default for SaaS. Both are designed for the developer-builder workflow rather than for marketing-team operators.

Analytics: PostHog or Plausible. PostHog for product analytics with feature flags and experiment infrastructure. Plausible for privacy-focused web analytics. Self-hosting either is straightforward; managed versions are cheap.

AI integration: Claude API plus Vercel AI SDK. The Claude API plus Vercel's AI SDK has become the dominant pattern for adding AI features. Anthropic's MCP integration is increasingly part of this stack.

Storage: Vercel Blob, Cloudflare R2, or AWS S3. Each has a niche. Vercel Blob for tight Next.js integration; R2 for egress-free egress-free storage; S3 for everything else.

Background jobs: Trigger.dev or Inngest. Both have matured into solid defaults for background processing in serverless environments. Trigger.dev's developer experience is excellent; Inngest's event-driven model is strong for complex workflows.

Monitoring: Sentry plus Vercel Analytics. Sentry for error tracking, Vercel's built-in analytics for performance. The free tiers cover small SaaS comfortably.

What's Different From the 2024 Stack

The shifts are specific.

Serverless databases have matured into defaults. In 2024, serverless Postgres was an interesting option. In 2026 it's the default — for solo founders and small teams especially, running your own database is rarely justified.

Auth has consolidated around Clerk. Auth was a "what do you use?" debate in 2024. In 2026, Clerk has substantial market share among indie builders, and the consolidation simplifies decisions.

Vercel AI SDK has emerged as the de facto AI integration layer. Direct API calls are still common, but the SDK abstracts the boilerplate enough that most new projects use it.

MCP integration is becoming standard. Connecting to third-party services through MCP servers is increasingly part of the stack, not a custom integration.

The "background jobs" question now has clear answers. This was a painful question in 2024. In 2026 there are two strong defaults.

The full-stack productivity has compressed. A solo founder can ship a credible B2B SaaS in days using this stack — auth, billing, basic UI, a working product — that would have taken weeks in 2024.

Where the Stack Still Forces Choices

The defaults handle most cases. Real decisions remain in a few areas.

UI library: shadcn/ui plus Tailwind has dominated, but is it forever? shadcn/ui's "copy components into your project" approach has been the dominant pattern. Some teams prefer Radix or Headless UI directly; some still use chakra-style libraries. shadcn/ui is the default but not a monopoly.

TypeScript strictness. Some teams run TypeScript in strict mode from day one; some take a "ship now, types later" approach. Both have proponents. AI-assisted development makes strict TypeScript more tractable than it used to be.

Monorepo vs. multi-repo. For solo founders with multiple projects, the monorepo question keeps coming up. Turborepo has won the monorepo tooling fight. Whether to actually adopt monorepo depends on how interconnected the projects are.

Mobile. React Native vs. Expo vs. Capacitor vs. native. Mobile development is less converged than web. Most B2B SaaS founders skip native mobile for v1; some can't.

What's Out

Several technologies that were defaults in 2024 are increasingly absent.

Heavy SaaS form builders. Most teams now build forms with shadcn/ui + react-hook-form + zod. The dedicated form builders have less use case.

Complex state management libraries. Redux, MobX, Zustand. The pattern is increasingly "server state in TanStack Query, UI state in React state, urls and search params for shareable state." Heavy state management libraries are rarely the right choice for new B2B SaaS projects.

Custom CSS frameworks. Tailwind has effectively won. Other CSS frameworks see less new adoption.

Self-managed Postgres for small projects. As mentioned, serverless Postgres has displaced this for most small projects.

Custom auth implementations. With Clerk and Auth.js, custom auth is rarely the right choice for new projects.

What Founders Should Do With This

Three practical recommendations.

Adopt the defaults unless you have a specific reason not to. The defaults are good for a reason — they've been tested at scale, they have strong ecosystems, and they reduce decision fatigue. Override them when you have specific knowledge that justifies an alternative, not by default.

Invest in stack fluency, not in stack research. The marginal benefit of choosing a slightly better tool is much less than the marginal benefit of being good with the tools you have. Master your stack rather than re-evaluating it constantly.

Stay current but skeptical of trends. The stack is moving. New tools that warrant consideration emerge each quarter. But most "amazing new tools" don't survive the next two quarters. Wait for adoption to settle before changing core stack components.

The Trajectory Through 2026 and Beyond

The convergence is continuing.

AI-native frameworks are emerging. Frameworks designed specifically for AI-augmented development workflows. Early days; worth watching but not yet defaults.

Edge compute is getting more capable. Vercel Edge, Cloudflare Workers, and similar platforms are becoming viable for more workloads. The stack increasingly assumes edge-capable deployment.

Privacy and compliance defaults are getting stronger. Stack components that handle GDPR, EU AI Act, and various US state laws by default are gaining share. The compliance burden is moving from the founder to the tools.

For founders, the practical takeaway is encouraging. The stack decisions that used to consume weeks of research have converged enough that defaults work for most projects. Decisions can focus on what's specific to the project — domain logic, customer research, market positioning — rather than on whether to use Postgres or MySQL or whether the front-end framework choice matters. The convergence is a gift to people building products. Take it and build.

We use cookies

We use cookies to ensure you get the best experience on our website. For more information on how we use cookies, please see our cookie policy.

By clicking "Accept", you agree to our use of cookies.
Learn more.