Why Most SaaS Boilerplates Choose Next.js (And When Not To)

TL;DR

Next.js runs in ~85% of SaaS boilerplates released in 2024-2026. The reasons are real: React ecosystem depth, Vercel deployment, Server Components, and the shadcn/ui component library. But if your team knows Remix better, or you need a multi-framework frontend, or you're building an API-first product — Next.js isn't always the answer.

The Numbers

A survey of popular SaaS boilerplates by framework:

Framework	Boilerplate Share	Examples
Next.js	~85%	ShipFast, Supastarter, Makerkit, T3, Epic Stack
Remix	~5%	Epic Stack (also supports Remix)
SvelteKit	~3%	SvelteLaunch, few indie starters
Nuxt	~2%	Nuxt SaaS starter
Other React	~3%	Vite SPA + separate API
Non-JS	~2%	Django Pegasus, Rails boilerplates

Why Next.js Wins for Boilerplates

1. React Ecosystem Lock-In (The Good Kind)

React has the largest component ecosystem. shadcn/ui, Radix UI, Headless UI, Tremor — all React. Every UI library authors support React first, if not exclusively.

When you build a boilerplate on Next.js, you get:

• Any React component library
• 60k+ shadcn/ui GitHub stars means components are well-tested
• Tightly typed with TypeScript support across the entire ecosystem

2. Server Components Change the Architecture

Next.js App Router (stable since v13.4) brings server-side rendering inline with components:

// Server Component — runs on server, no client JS
// No useEffect, no loading states, no API route needed
async function UserDashboard({ userId }: { userId: string }) {
  const user = await db.user.findUnique({ where: { id: userId } });
  const recentActivity = await db.activity.findMany({
    where: { userId },
    take: 10,
    orderBy: { createdAt: 'desc' },
  });

  return (
    <div>
      <h1>Welcome back, {user.name}</h1>
      <ActivityFeed items={recentActivity} />
    </div>
  );
}

No API route. No client-side fetch. The data is fetched at render time on the server. This simplifies auth, reduces client JS, and improves initial page load.

3. Vercel Integration

Vercel built Next.js and deploys it perfectly:

• Zero-config deployment on git push
• Edge Functions for auth middleware
• Image optimization built in
• Analytics and Speed Insights

Most SaaS founders use Vercel to start, which makes Next.js the frictionless choice.

4. Full-Stack in One Codebase

/app
  /api
    /webhooks/stripe/route.ts    ← Stripe webhooks
    /auth/[...nextauth]/route.ts ← Auth endpoints
  /(dashboard)
    /page.tsx                    ← Protected pages
  /(marketing)
    /page.tsx                    ← Public pages
/components
/lib

Backend API routes, frontend pages, middleware, server actions — all in one repo, one deploy, one framework. No microservices complexity for an early-stage product.

5. The boilerplate Authors Know It

Boilerplate authors ship what they know and what their customers buy. Marc Lou (ShipFast), Remigiusz Wierzbicki (Supastarter), and most indie hackers know Next.js deeply and build on it.

---

When NOT to Use Next.js

When to Choose Remix

Remix has better data loading primitives for form-heavy apps:

// Remix loader + action — clean separation
export async function loader({ request }: LoaderFunctionArgs) {
  const user = await getUser(request);
  return json({ user, projects: await getProjects(user.id) });
}

export async function action({ request }: ActionFunctionArgs) {
  const formData = await request.formData();
  const name = formData.get('name') as string;
  return await createProject({ name, userId: user.id });
}

// Component gets both from hooks — no useState, no fetch
export default function Projects() {
  const { user, projects } = useLoaderData<typeof loader>();
  // ...
}

Choose Remix if: Your app is highly form-driven, you need progressive enhancement (forms that work without JS), or your team comes from a Rails/Django background.

When to Choose SvelteKit

SvelteKit is genuinely smaller and faster than Next.js for specific use cases:

Metric	Next.js	SvelteKit
Client JS baseline	~90KB	~20KB
Build time	Slower	Faster
Learning curve	Higher	Lower
Component ecosystem	Massive	Smaller

Choose SvelteKit if: Bundle size is critical (media, international markets with slow connections), you're not dependent on React-specific libraries, or your team prefers Svelte's reactivity model.

When to Build API + React SPA

If your product needs a desktop app, mobile app, AND web — a separate API + shared React frontend might make more sense:

/apps
  /web         ← React SPA (Vite)
  /mobile      ← React Native (Expo)
  /desktop     ← Electron (uses web bundle)
/packages
  /api         ← Hono/Express API
  /types       ← Shared TypeScript types

Next.js adds complexity here: SSR doesn't help mobile/desktop clients, and you're duplicating API logic.

Choose API + SPA if: Multi-platform is a core requirement from day one.

When to Choose a Non-JS Stack

Choose Django/Rails if:

• Your team is primarily Python/Ruby
• You need heavy data processing (pandas, numpy integration)
• Enterprise clients require specific compliance frameworks
• You're building a content-heavy app that benefits from mature CMS plugins

---

The Honest Assessment

Next.js isn't the best framework — it's the most popular framework at a time when boilerplate authors need to maximize sales.

What Next.js does better:

• Developer ecosystem (components, tooling, community)
• Deployment simplicity
• Full-stack in one

What Next.js does worse:

• Bundle size (heavy React + Next.js runtime)
• Cold start times (App Router has overhead)
• Complexity (App Router + Server Components have a steep learning curve)
• Vendor risk (Vercel controls the roadmap)

If you're choosing a boilerplate for a real project, pick the one that fits your team's expertise first, framework second.

---

Compare Next.js boilerplates and alternatives on StarterPick.