A Next.js 16 SaaS boilerplate is a starter codebase that is actually written against Next.js 16 conventions, not a Next.js 14 or 15 project with the version number bumped in package.json. The distinction matters because the framework major version decides how much of the boilerplate you can keep untouched. Next.js 16 removed synchronous request APIs, renamed middleware.ts to proxy.ts, made Turbopack the default bundler and replaced the PPR flag with Cache Components. A boilerplate written for the old conventions hands you those migrations on day one, which is exactly the work you paid to skip.
This post covers three things: what changed in Next.js 16 that a SaaS codebase feels, a checklist to verify a boilerplate is genuinely on 16, and how NEXTY.DEV handles each item.
Why the framework major matters when choosing a boilerplate
The value of a boilerplate is the distance between git clone and the first paying customer. Every breaking change the vendor has not absorbed becomes your migration, and migrating code you did not write is slower than migrating your own. Three concrete consequences:
- Dependencies. Auth, ORM, i18n and UI libraries each need a React 19.2 compatible release. Older pins mean you upgrade them one at a time and fix the fallout.
- Conventions.
proxy.ts, asyncparamsanddefault.jsfor parallel routes are spread across every route segment. Mechanical, but wide. - Support horizon. Vendors who shipped 16 early tend to keep pace with 16.x minors. Vendors still on 15 will make you wait for the next major too.
What changed in Next.js 16 that a SaaS boilerplate feels
Everything below comes from the official release post and upgrade guide, with a note on why each item matters for a SaaS codebase.
Turbopack is the default bundler for dev and build
next dev and next build use Turbopack without any flag. If the project has a custom webpack configuration, next build fails unless you pass --webpack. The experimental.turbopack key moved to a top-level turbopack option.
Why it matters: boilerplates often carry webpack tweaks for SVG loaders or Node polyfills. Those must be ported to turbopack.resolveAlias or removed. Scripts that still say next build --webpack mean the migration is unfinished.
proxy.ts replaces middleware.ts
Rename the file and the exported function to proxy. The proxy runs on the Node.js runtime; edge is not supported there. middleware.ts still works for edge use cases but is deprecated.
Why it matters: locale routing, auth redirects and rate-limit gating usually live here. Node APIs become available, but any edge-only assumption has to be revisited.
Synchronous request APIs are gone
cookies(), headers(), draftMode(), params and searchParams are async only; the Next.js 15 compatibility shim was removed. params and id in opengraph-image, icon and sitemap are Promises as well.
Why it matters: session checks, tenant lookups and locale resolution read these at the top of every layout and page. The next-async-request-api codemod handles most of it, but a boilerplate should ship this way so you never run it.
Cache Components replace the PPR flag
experimental.ppr, the route-level experimental_ppr export, experimental.dynamicIO and experimental.useCache were all removed. Partial Prerendering is now opted into with cacheComponents: true and the "use cache" directive. Caching is explicit; dynamic code in pages, layouts and route handlers runs at request time by default.
Why it matters: request-time by default is right for authenticated dashboards. Enabling cacheComponents is not a rename: it can surface build errors for uncached data outside <Suspense>. A boilerplate should adopt it deliberately or leave it off, not carry the old flags.
Caching APIs: revalidateTag, updateTag, refresh
revalidateTag() now requires a cacheLife profile as the second argument (revalidateTag('posts', 'max')); the single-argument form is deprecated. updateTag() is a new Server Actions-only API with read-your-writes semantics, and refresh() re-renders uncached data from a Server Action.
Why it matters: settings forms, admin CRUD and billing status are exactly the flows that want updateTag(). A boilerplate still calling single-argument revalidateTag() ships TypeScript errors.
React 19.2 and the React Compiler
The App Router in Next.js 16 uses the React Canary channel with React 19.2 features (View Transitions, useEffectEvent, <Activity/>). React Compiler support is stable via reactCompiler: true, off by default.
Why it matters: every client-side dependency has to be React 19 compatible. This is where older boilerplates usually break: a form library or UI kit pinned to a React 18 peer dependency.
Toolchain floor and removals
Node.js 20.9+ and TypeScript 5.1+ are the minimums. next lint is removed and next build no longer lints. AMP, serverRuntimeConfig and publicRuntimeConfig are gone in favor of environment variables. Parallel route slots require an explicit default.js. next/image defaults changed (minimumCacheTTL 4 hours, qualities [75], redirects capped at 3).
Why it matters: CI images, lint scripts, Dockerfiles and env-var strategy all get touched. None of it is hard; all of it is time.
Checklist: is the boilerplate really on Next.js 16?
Run this against the repository before you buy.
| Check | What to look for | Why it matters |
|---|---|---|
| App Router only | No pages/ directory; every route under app/ | Next.js 16 features (Cache Components, new caching APIs) are App Router only |
proxy.ts, not middleware.ts | File named proxy.ts with export function proxy | middleware.ts is deprecated; the runtime is now Node.js |
| Async request APIs | await params, await cookies(), await headers() everywhere | Sync access was removed; the old shim no longer exists |
| Turbopack build passes | Scripts are plain next build; no webpack() in next.config | A --webpack flag means the migration is unfinished |
| React 19.2 compatible deps | Auth, ORM, forms, UI kit at React 19 compatible releases | Peer dependency conflicts surface only at install or runtime |
| i18n on the new APIs | Locale resolved from awaited params, routing in proxy.ts | Locale plumbing runs on every request |
| No removed config | No experimental.ppr, experimental_ppr, next lint, serverRuntimeConfig | These fail the build or the type check on 16 |
| Node 20.9+ everywhere | engines, Dockerfile, CI matrix | Node 18 is unsupported |
Parallel routes have default.js | Every @slot folder has one | Builds fail without it |
| 16.x minors tracked | Changelog shows updates after 16.0 | Proves the vendor is maintaining, not just tagging |
A three-command spot check:
ls proxy.ts middleware.ts pages 2>&1
grep -n '"next"\|"react"\|"react-dom"' package.json
grep -rn "next lint\|--webpack\|experimental_ppr" package.json next.config.* app 2>/dev/null
Expected: proxy.ts exists, middleware.ts and pages do not, next is 16.x, react is 19.2.x, the last grep is empty.
How NEXTY.DEV handles each item
NEXTY.DEV is a Next.js SaaS boilerplate sold as a one-time license, and nexty.dev itself is built on the same template, so the claims below can be checked against a production deployment.
| Checklist item | NEXTY.DEV |
|---|---|
| App Router only | Every route lives under app/[locale]/; there is no pages/ directory |
proxy.ts | Locale routing runs through next-intl inside export async function proxy |
| Async request APIs | Layouts and pages await params to resolve the locale before anything else |
| Turbopack build | Plain next build, no custom webpack configuration |
| React 19.2 deps | nexty.dev runs Next.js 16.2 with React 19.2; Better Auth, Drizzle ORM, next-intl 4 and the AI SDK are all on React 19 compatible releases |
| i18n | English, Chinese and Japanese via next-intl, locale taken from awaited params |
| Removed config | None of the removed flags are present; type check runs with tsc --noEmit |
Beyond the framework surface, this is what the template ships, per the documentation:
- Authentication. Better Auth with Google and GitHub OAuth, email OTP and Magic Link, plus Cloudflare Turnstile and login rate limiting. Since v3, Better Auth and Drizzle replaced the Supabase-based auth of v1 and v2.
- Database. Drizzle ORM against Supabase, Neon or self-hosted PostgreSQL, configured with a single
DATABASE_URL; tables for users, pricing plans, orders and content included. - Payments. Stripe, Creem and PayPal: subscriptions, one-time payments and a credit system for usage-based billing, with pricing plans managed visually from the admin dashboard.
- AI. Vercel AI SDK with OpenRouter, Replicate and fal.ai, plus a demo hub for chat, text-to-image, image-to-image and video generation.
- Content. MDX static blog plus an admin CMS with access control (public, logged-in, subscriber-only), AI translation and draft, published and archived states.
- Infrastructure. Cloudflare R2 storage with admin file management, Resend email with a newsletter module, Upstash Redis for caching and rate limiting, user and admin dashboards.
- Deployment. Vercel, Cloudflare Workers, Dokploy and Coolify.
Pricing is one number: the Pro license is a $188 one-time payment with lifetime updates, delivered as access to the private GitHub repository, and it includes a second boilerplate, nexty-directory, for directory and listing sites. A free open-source starter with a reduced feature set (i18n, newsletter, analytics, static blog; no database, auth, payments, AI or storage) exists for projects that do not need the SaaS layer. Details are in the pricing section.
What if your project is still on Next.js 15?
Two situations, and they are not the same.
You bought NEXTY.DEV. The license is permanent access to the private repository. The template itself already runs on Next.js 16, and every later upgrade lands in the same repository, so you download the new version instead of migrating the template yourself. The only Next.js 15 code you can own is a project you started on an earlier release of the template, and the work then is on your own project, not on the template.
You are on another boilerplate that is still on 15, or you have an older Nexty-based project you want to move forward rather than rebuild. Start with the official codemod, then run the async request API codemod separately, because the upgrade codemod does not include it:
npx @next/codemod@canary upgrade latest
npx @next/codemod@canary next-async-request-api .
The full walkthrough, including the next-devtools-mcp route where an agent does most of the mechanical work, is in How to Upgrade a Next.js 15 Project to Next.js 16. It is the process used to bring NEXTY.DEV itself to 16, so it maps one to one onto a project built from the template.
FAQ
Is Next.js 16 stable enough for a production SaaS?
Yes. Next.js 16 shipped in October 2025 with Turbopack stable for dev and build, and the 16.x line has had several minor releases since. NEXTY.DEV and nexty.dev have run on it in production since late 2025.
Do I have to enable Cache Components to use Next.js 16?
No. cacheComponents is opt-in. Without it, pages and layouts render at request time, which is correct for authenticated dashboards. Enable it when you have static shells that benefit from Partial Prerendering.
Does a Next.js 16 boilerplate still work with the edge runtime?
proxy.ts runs on Node.js only. For edge request interception, middleware.ts still works but is deprecated. Route handlers and pages can still declare the edge runtime where the host supports it.
What does "lifetime updates" mean in practice?
You are added as a collaborator on the private GitHub repository. Every update, including the Next.js 16 migration and future major upgrades, lands there and you pull on your own schedule. No renewal, no subscription.
Where to start
If you are choosing a boilerplate today, run the checklist above against whatever you are considering. If you want one that already passes it, NEXTY.DEV is a Next.js SaaS boilerplate on Next.js 16 and React 19.2 with Better Auth, Drizzle, Stripe, i18n, AI SDK, CMS and R2 in place. Read the introduction for the full feature list, then check the pricing when you are ready.
