next-saas-stripe-starter: a modular Next.js 16 SaaS base with Stripe and Better Auth

Who the next-saas-stripe-starter is for, and what it refuses to be

The README is direct about the target: teams that keep rebuilding the same day-one surface. Auth, organizations, subscriptions, an admin panel, docs, a blog and a changelog, all present, and, in the README's words, "every part of it can be switched off or deleted for good." That second clause is what separates this from a demo repository. The stated goal is subtraction, not accumulation.

It is not a framework and not a hosted product. It is a Next.js 16 App Router application you copy with create-next-app and then edit in place. There is no plugin API, no runtime extension point, and no upgrade path that preserves your changes, which is the normal bargain for starter kits and worth naming plainly. If you want to keep receiving upstream improvements without merging, this is the wrong shape of project.

The stack is fixed rather than configurable: Neon Postgres through Drizzle ORM, Better Auth for Google sign-in and organizations, Stripe for Checkout, the customer portal and webhooks, Tailwind CSS v4 with shadcn/ui and Base UI, and Fumadocs over MDX for docs, blog, changelog and legal pages. Choosing this starter means choosing all of those.

Feature flags, module dependencies and the prune command

Every module is a flag in config/features.ts. The README lists six: auth, billing, admin, docs, blog and changelog. Turning one off is not only about hiding links. According to the README, its routes return 404, its links disappear and its endpoints are refused.

The rule that matters most is the dependency rule, and it is the part most starter kits get wrong. A module stays off while a module it depends on is off, or while a service it requires is missing its environment variables. So billing depends on auth and requires Payments; admin depends on auth. This means a half-configured checkout does not silently produce a broken pricing page. It produces an absent one. In development a flag button in the bottom-right corner shows the state of everything; in production you set default: false on the module and rebuild.

Deletion is a separate, explicit step. The prune script prints what it would remove before removing anything: routes, components, content, packages, and any link left pointing at a removed route. That last item is the one that catches people who delete modules by hand. The dry run is the default, so the safe invocation is the one you type first.

Installing the starter and getting a first page running

The README gives the bootstrap as create-next-app pointed at the repository, then install, then copy the environment file. Nothing has to be complete on the first run, because a module stays off until its services are configured.

npx create-next-app my-saas --example "https://github.com/mickasmt/next-saas-stripe-starter"
cd my-saas
pnpm install
cp .env.example .env.local

Then apply migrations and start the dev server. The migrate script runs drizzle-kit migrate, and the environment file explains why there are two database URLs: DATABASE_URL is the pooled Neon connection the app uses, DATABASE_URL_UNPOOLED is the direct connection drizzle-kit uses for migrations.

pnpm db:migrate
pnpm dev

To test subscriptions locally you forward Stripe events in a second terminal. The path in the README is /api/auth/stripe/webhook, and the matching STRIPE_WEBHOOK_SECRET comes from the same command.

stripe listen --forward-to localhost:3000/api/auth/stripe/webhook

The environment file also documents the Google side: GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET with a redirect URI of http://localhost:3000/api/auth/callback/google, plus NEXT_PUBLIC_GOOGLE_CLIENT_ID for the One Tap prompt, which needs the site listed under Authorized JavaScript origins and can be turned off by leaving it empty. If you want to see what pruning looks like before you commit to a module set, the dry run is a single command.

pnpm modules:prune blog changelog

Without --yes the command only prints what it would delete, so a first run costs you nothing but a read.

The free tier stops before teams, seats and email

The README's own comparison table is the clearest limitation. The free repository includes the modules, the dev panel and the prune command, auth with organizations, Stripe subscriptions and the customer portal, the admin panel, and docs, blog and changelog. It does not include the guided onboarding flow, team invitations with owner, admin and member roles, seat-based team billing, transactional email templates through Resend, two-factor authentication and session revocation, real user management with bans and login-as-user, or Sentry error monitoring.

That list is worth reading twice, because "auth with organizations" in the free tier suggests a team product and the rest of the table says otherwise. If your product charges per seat or sends anything beyond Better Auth's own mail, you are looking at the Pro version or at building those pieces yourself. The README states plainly that Pro is not part of the repository and that every "About Pro" link in the app points back to the README section, so the free repository does not ship a stub you can grow into.

A second constraint is smaller but real: the README documents Google as the sign-in provider, and the environment file only carries Google credentials. Better Auth supports more, but nothing in the repository shows a second provider configured, so treat additional providers as work you own.

How this differs from Next.js SaaS starters built on Supabase or Clerk

The related searches around this project point at a crowded field: Supabase-based Next.js starters, Blazity's next-saas-starter, BoxyHQ's SaaS starter kit, ixartz's SaaS Boilerplate. The difference here is where the integration weight sits.

Supabase-based starters centralize auth, database and row-level security in one vendor, and authorization tends to live in database policies. This starter splits those concerns: Better Auth owns identity and organizations, Drizzle owns the schema and migrations, and authorization is checked in server actions and route handlers. That is more code you can read and change, and less behaviour hidden behind policies you have to reason about from outside.

Clerk-based starters push auth into a hosted service with its own dashboard. Better Auth runs in your application against your database, which means the user and organization tables are yours and the migration history is yours. The cost is that you operate the auth surface, including the generated schema file, and the benefit is that no auth decision is gated behind a vendor's plan tier.

The billing difference is narrower. Stripe Checkout, the customer portal and webhooks are the same primitives most starters use. What this one adds is that plan prices are read from Stripe rather than duplicated in a config file, which removes one class of drift between your pricing page and your dashboard.

Maintenance, licence and what an upgrade actually costs

The repository is MIT licensed, which permits commercial use, modification and redistribution with the licence and copyright notice retained. That is a permissive starting point, but it says nothing about the paid Pro version, which is sold separately and is not part of this repository. Whether Pro carries its own terms is not something the README addresses, so check before you plan around it. None of this is legal advice.

The last push to the repository was on 2026-09-28, and v2.0.0 was released on 2026-09-26, after v1.0.0 in June 2024. That gap is the honest signal about upgrade cost. A starter that jumps a major version after two quiet years is likely to have moved several dependencies at once, and the stack table shows pinned versions across Next.js 16.3.4, React 19.2.8, better-auth 1.7.5 and fumadocs 16.15.11. Upgrading means re-resolving that whole set, not bumping one package.

The generated auth schema is the specific friction point. The auth:generate script writes lib/db/schema/auth.ts from the Better Auth configuration and then formats it, so that file is output rather than source. If you hand-edit it, the next generation overwrites your changes. Keep customizations in the Better Auth config and regenerate.

Because the starter is copied rather than installed, upstream fixes do not reach you automatically. Pulling them means diffing against your own tree, which grows more expensive with every module you prune and every file you rewrite. Budget for that before you start, not after.

Editorial conclusion

Adopt it if you are starting a Next.js 16 App Router product and want auth, organizations, Stripe subscriptions, an admin panel and MDX content wired before you write business logic, and if you accept that Google is the only sign-in provider documented in the README and that team invitations and seat-based billing live in the paid Pro version rather than this repository. Skip it if your product needs a different auth provider, a non-Stripe billing system, or a database other than Neon Postgres; the stack table is a commitment, not a menu. Before you commit, run pnpm modules:prune blog changelog without --yes and read the dry-run list, then confirm the Better Auth schema generation step (pnpm auth:generate) reproduces lib/db/schema/auth.ts on your machine, because that file is generated rather than hand-written and is the piece most likely to surprise you during an upgrade.

Frequently asked questions

Official sources

1. License: MIT
2. mickasmt/next-saas-stripe-starter on GitHub
3. Project website
4. README
5. Releases