You have decided to build a SaaS. You have also decided not to start from scratch. Good. Now you are looking at a dozen boilerplates that all claim to save you weeks, and you do not know which one to trust.
This is not a ranked list. It is a decision framework -- five questions that cut through feature marketing and tell you whether a boilerplate will actually get you to your first paying user faster.
Switching boilerplates mid-build is painful. You have learned the project structure, wired up your domain model, and built several features. When you hit a blocker -- an auth system that cannot do what you need, a payments integration that does not handle webhooks -- the cost is not just the migration hours. It is the momentum you lose.
Spend thirty minutes evaluating before you clone anything.
Some boilerplates use a hosted auth provider like Clerk, Auth0, or Supabase Auth. Others wire up JWT or session-based auth directly, storing users in your own database.
Hosted auth is fast to set up. But it comes with a monthly bill, a user cap on free tiers, and a migration cost if you ever want to move. If you are building for enterprise customers who ask about data residency, "our users live in Clerk" is not a comfortable answer.
Look for a boilerplate that stores users in your own database, hashes passwords with bcrypt, and uses JWT for API auth. You can always add OAuth or magic links on top -- but the base layer should be yours. See how this works in practice in JWT auth in Next.js App Router without NextAuth.
Every boilerplate claims "Stripe included." What that usually means is a Stripe checkout button and maybe a webhook handler for one event. That is about 20% of what you need.
The full picture: Stripe Checkout session creation, webhook handling for payment events, customer portal for self-service billing, subscription status synced to your database, plan-gating in your service layer, and a working cancel flow. If the boilerplate only shows you how to create a checkout session, you will build the rest yourself.
Ask: does it handle customer.subscription.updated, invoice.payment_failed, and the customer portal? Those are the events that matter after the first payment. For a complete reference, see Stripe subscriptions in Next.js -- checkout, webhooks, and customer portal.
Hosted databases simplify setup. But if your boilerplate hard-codes a connection to one provider, you are locked in -- and some of these services have changed pricing or terms in ways that surprised early-stage founders.
The safest setup is a PostgreSQL connection string your boilerplate reads from an environment variable. You can point it at Neon, Railway, Supabase, Render, or your own server. Neon is the recommended default -- serverless Postgres that scales to zero, with a free tier that lasts through early validation and a branching feature that makes schema migrations less scary.
If you are using Claude Code to build your product -- and in 2026, most solo founders and small teams are -- the boilerplate's Claude configuration matters as much as the code itself.
A Claude-ready boilerplate ships with a CLAUDE.md that documents the project structure, naming conventions, and commands. It includes skills (step-by-step task definitions that Claude follows) for common tasks like adding a feature module, wiring an API route, or setting up Stripe. Without this, Claude generates plausible-looking code that drifts from your actual conventions and creates a codebase only it can maintain.
The difference: a boilerplate with good Claude configuration lets you describe a feature in plain English and get working code that fits your codebase. Without it, you spend time correcting patterns on every prompt.
Your MVP will not look like your v2. The boilerplate that gets you to launch is not always the one that scales with your product.
A DDD-lite module structure -- schema, types, validation, repository, service, and index in one folder per entity -- is a sign the boilerplate was designed for codebases that grow. Each feature is self-contained. Adding a new one does not require touching three other files. A new developer, or Claude, can understand what any module does without reading the whole codebase.
A single 2000-line file with all the business logic is a sign the boilerplate was not.
| Criteria | What you get |
|---|---|
| Auth ownership | JWT + bcrypt, users in your own database, no third-party auth vendor |
| Payments end to end | Stripe subscriptions, one-time payments, webhooks, plan gating, cancel flows, customer portal |
| Data location | Neon DB by default, any PostgreSQL connection string via environment variable |
| Claude Code ready | CLAUDE.md, skills, hooks, and MCP servers pre-configured out of the box |
| Upgrade path | DDD-lite modules, each feature self-contained and independently testable |
If you want to see how this compares to no-code tools instead of other boilerplates, Next.js SaaS Boilerplate vs No-Code covers that decision.
After you have checked the criteria above, ask yourself: if I start with this boilerplate today, when can I take my first payment?
If the answer is "after I wire up webhooks, build the cancel flow, set up email, and add auth" -- that is not a boilerplate, that is a starting point. If the answer is "this weekend" -- that is what you are looking for.
Get the boilerplate and launch your idea at boilerplate.iteam-company.com.