play-nextjs: a Next.js SaaS boilerplate with auth, Prisma and Stripe wired in

The template bundles four integrations rather than one

The pitch in the README is a free and open-source SaaS starter kit and boilerplate for SaaS startups, apps and businesses, with what it calls a premium design plus essential UI components and pages.

The integrations are the substance, and there are four. PostgreSQL for the database, integrated with Prisma, described as an open-source relational database system that ensures data integrity and reliability. NextAuth for authentication, for secure login and user management. MDX for blogs, described as uniquely combining Markdown and JSX, with a complete blogging solution for creating and maintaining a blog. And Stripe for subscription payments, with a global payment processing platform offering secure checkout.

The pages that come with it are named in the README too: login, signup, blog, about, and others, each handcrafted to offer what the README calls top-notch aesthetics while maintaining usability. The components are described as crafted using TailGrids components, and the styling is Tailwind CSS as a utility-first framework.

The reason a template like this is worth reading carefully rather than just cloning is that the integration wiring is the hard part. A schema, an auth flow, a checkout page and a billing webhook have to agree with each other, and a template that already agrees is worth more than a set of unconnected screens. The live demo is at play.nextjstemplates.com and the documentation is at nextjstemplates.com/docs.

The install needs --legacy-peer-deps, and the reason is React 19

The setup instructions are four steps, and step three carries a note that tells you more about the state of the template than any of the marketing does.

You download and extract the template from Next.js Templates, change into the template directory with `cd`, install dependencies, and start the dev server. The install command is:

    npm install --legacy-peer-deps

The note attached to it says that as of right now React 19 causes peer dependencies issues with some packages, so the `legacy-peer-deps` flag is required. That flag tells npm to ignore peer dependency resolution entirely, which is a blunt instrument: it will let the install succeed even when the versions you end up with are not the combination the package authors intended.

Then the dev server:

    npm run dev

Which launches the template on localhost:3000.

The manifest explains the React 19 situation. The dependencies list `react` and `react-dom` at `^19.2.0` and `next` at `16.0.10`, and the dev dependencies include `eslint-config-next` at 15.1.6, which is a major version behind the Next.js the template runs on. That gap is consistent with the peer dependency conflict the flag works around, and it is the kind of detail that only shows up when you install it yourself.

For a production deployment the README points at one-click buttons for Vercel and Netlify, and says both provide generous free tiers for hosting Next.js projects. The deployment path assumes the project is on a GitHub repository.

Prisma drives the database layer and runs before every build

The `package.json` scripts are short and they say something about how the data layer is wired.

`dev` runs `next dev`, `build` runs `prisma generate && next build`, `start` runs `next start`, and `lint` runs `next lint`. The Prisma generate step running as part of the build is the notable one, because it means the client is regenerated from the schema every time you build rather than being committed. The repository has a `prisma/` directory, a `prisma.config.ts` at the root, and a `schema.json`.

The Prisma side is current. The dependencies include `@prisma/client` and `@prisma/adapter-pg` at `^7.0.1` with `prisma` itself at `^7.0.1`, plus `@auth/prisma-adapter` at `^1.5.0`, which is the piece that lets NextAuth store its session and account records in the same Prisma-backed database as the rest of the application.

The environment file shows the full set of things the template expects to be configured. It needs a `SECRET` for NextAuth and a `NEXTAUTH_URL`, plus `NEXT_PUBLIC_SITE_URL`. It has GitHub and Google OAuth client id and secret pairs. It has `STRIPE_SECRET_KEY` for billing. It has a group of Sanity-related public variables, `NEXT_PUBLIC_SANITY_PROJECT_ID` and `NEXT_PUBLIC_SANITY_PROJECT_TITLE`, alongside `SITE_URL`, `SITE_NAME` and `AUTHOR_NAME` for the site metadata. It needs `DATABASE_URL` for Prisma.

And it has a full email configuration, `EMAIL_SERVER_HOST`, `EMAIL_SERVER_PORT`, `EMAIL_SERVER_USER`, `EMAIL_SERVER_PASSWORD` and `EMAIL_FROM`, with `nodemailer` at `^7.0.11` in the dependencies.

The `NEXT_PUBLIC_` prefix is worth noting for anyone editing this file. Those variables are inlined into the client bundle at build time, so a value that should stay secret cannot use that prefix.

The environment file is the real specification of what the template does

The `.env.example` file is the most useful document in the repository, because it is the complete list of external services the template talks to, and reading it tells you which features are wired and which are stubs.

Two services are optional in practice. The Sanity variables are public identifiers for a project and its title, and the README's feature list does not mention Sanity at all, which suggests it is a leftover from a CMS-shaped variant of the template rather than a core dependency of what is described. The email variables, by contrast, line up with the authentication story, because a magic link or password reset flow needs somewhere to send mail, and the update log records the magic link signin and forgot password features being integrated in March 2024.

The OAuth pairs matter for the same reason. The README describes NextAuth as providing secure login and user management, and the presence of both GitHub and Google client id and secret pairs means the template ships with social sign-in wired rather than leaving you to write the provider configuration.

The `DATABASE_URL` on its own tells you the shape of the data story. There is one relational database, accessed through Prisma, and it holds the auth tables as well as the application tables, given the presence of `@auth/prisma-adapter`.

For a reader evaluating the template, the practical exercise is to open this file and count the services you actually want to run. Every one of them is an account to create, a key to rotate and a failure mode to handle, and the ones you do not need should be deleted rather than left as empty placeholders in a file that ships to production.

The update log tracks framework majors, which tells you the upgrade cost

The update log in the README is the most useful section for judging how much work an upgrade will be, and it is a running record of framework migrations.

The entries are dated. 03 December 2025, v2.2.2, upgraded to Next.js 16, updated Prisma to the latest version, updated Tailwind CSS to the latest version. 06 August 2025, v2.2.1, moved context providers to `/src/app/providers.tsx` and removed the initial loader. 10 April 2025, a peer deps fix and a Next.js update for a security patch. 29 Jan 2025, upgraded to Next.js 15, switched to using `Link` instead of the `a` tag, and fixed minor bugs. 21 March 2024, upgraded to Next.js 14, updated the Stripe integration, fixed auth issues, updated all the packages, updated the ts config, redesigned the signin and signup pages, and integrated magic link signin and forgot password.

Read as a sequence, that is a major Next.js version roughly every nine months, each time accompanied by a Stripe touch, an auth touch and a Tailwind touch. The v2.2.1 entry is the most instructive because it is a structural change rather than a dependency bump. Moving context providers into the app router and deleting the initial loader changes how your app composes, and it is the kind of edit that a user of the template has to make in their own copy.

The repository metadata says there are no GitHub releases, so the update log in the README is the version history. The current package version is 2.2.2, matching the December 2025 entry, and the last push was on 2026-05-19 with the repository not archived.

The overall picture is a template that is maintained in the sense that someone upgrades it against new framework majors, but there is no upgrade path for a user. You get a snapshot. When Next.js 17 arrives, the template maintainer will do the work in their copy, and you will either port it by hand or start from a diff.

Compared with assembling the same stack yourself and with a hosted template shop

There are two other ways to end up with a Next.js SaaS application, and each is a reasonable choice depending on what you are optimizing for.

Assembling it yourself means choosing Prisma, NextAuth and Stripe and writing the wiring. The difference in approach is that the template has already made the decisions you would otherwise spend a day on, and it has made them in a particular way. The `@auth/prisma-adapter` choice, the `next-auth` 4.x line rather than the newer Auth.js naming, the presence of both `axios` and `remark` and `remark-html` alongside `gray-matter` for the blog, and the `next-themes` package for dark mode are all decisions embedded in the dependency list. You inherit all of them.

The template shop route, which is where this one sits, sells the same thing with a different deal. You get a design you could not have drawn yourself, in exchange for the code being a starting point rather than a dependency. The README is explicit that it is free and open-source and that you can use it for both personal and commercial projects, which removes the licensing question that usually comes with a paid template.

The third option is a framework rather than a template, where the pages and components are generated from a schema and the whole thing is versioned as a dependency. The difference there is that upgrades arrive with `npm install` instead of with a diff. The cost is that the framework's abstractions become your abstractions, and the pages it generates are the pages you get.

For a founder who wants to be running in a week and does not intend to publish a framework, a template is the pragmatic answer. The thing to watch is the second-order cost. Once you have changed a page, copied a component, or added a migration of your own, the template has become your codebase, and the template's future value to you drops to the value of the parts you never touched.

Editorial conclusion

Adopt play-nextjs if you want a working Next.js SaaS skeleton this week, with authentication, a database schema and subscription billing already connected, and you are willing to own the code it leaves in your repository. Do not adopt it as a framework to depend on, since it is a copy-and-modify template with no upgrade path once you diverge. Verify first that your Node version satisfies the engines requirement of 20 or newer, that the `--legacy-peer-deps` install still resolves cleanly with your dependency set, and that the Prisma schema and Stripe products in the template match what you intend to sell.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NextJSTemplates/play-nextjs on GitHub
4. Project website
5. README