Open SaaS: a Wasp-based SaaS starter with auth, payments and jobs already wired

What Open SaaS actually solves, and for whom

Every subscription web app needs the same unglamorous parts: sign-up and login, a billing flow, transactional email, file upload, a landing page, and some way to run scheduled work. Open SaaS ships those as one repository instead of leaving them as a checklist. The README describes it as a template that is fully open-source, free to use and distribute, and ready to work with AI coding tools.

The intended user is a small team or solo developer who has chosen React on the front end and NodeJS with Prisma on the back end. The template is not a library you import into an existing project. It is a starting point you copy, then edit. That distinction matters more than the feature list: adopting it means adopting its directory structure, its configuration file format and its build tool.

The repository is organised around that copy-first model. There is a template/ directory holding the starter itself, a template-test/ directory, an opensaas-sh/ directory for the project's own site, and a tools/ directory described in the README as holding development tools used to maintain derived projects. The template is the product; the other directories exist to keep it working.

The Wasp layer is what makes the feature list short

Open SaaS does not implement authentication, jobs or deployment itself. It delegates them to Wasp, and the README is explicit about which Wasp features it leans on: full-stack authentication with email verification and social providers, end-to-end type safety with inferred front-end types, background jobs and queues defined in the config file, and one-command deploy to Railway or Fly.io.

That is the real mechanism. In a conventional NodeJS project, auth means choosing a library, wiring sessions, writing middleware and keeping client and server types in sync by hand or with a code generator. Here, the README states that email-verified auth and social auth take a few lines of code, and that backend function types are inferred on the front end without installing third-party libraries. Jobs follow the same pattern: you define a function in the config file rather than standing up a separate worker process and queue.

The cost is coupling. Wasp is the build system, the router and the data layer configuration format. If Wasp's model does not fit a requirement, you are not editing a file inside a normal React app; you are working against the framework's abstractions. The README frames this positively, and for the target user it mostly is, but it is a real constraint worth naming.

The surrounding stack is conventional. Astro's Starlight template handles documentation and blog pages. ShadCN UI provides components and styling, including an admin dashboard. Plausible or Google Analytics handle traffic measurement. OpenAI's API appears with a function-calling example. AWS S3 handles uploads, and SendGrid, Mailgun or SMTP handle email.

Installing Open SaaS and running it once

The README gives a two-command path. First install the Wasp CLI globally. The README specifies macOS, Linux, or Windows with WSL.

npm i -g @wasp.sh/wasp-cli

Then create a new app from the SaaS template. This copies a clean version of the template into a new directory rather than cloning the repository with its history and maintenance directories.

wasp new -t saas

After that, the README points to the Open SaaS Docs at docs.opensaas.sh for everything else, describing them as covering installation, pulling updates to the template, integrating services, SEO and deployment. That is where you will find the environment variables for your chosen payment provider, email service and S3 bucket. The README itself does not list them, so treat the docs as required reading before the first real run rather than optional.

If you contribute to the repository rather than copy it, the root package.json defines the quality scripts. Prettier and ESLint run in CI, and the README notes both checks are automatic in the pipeline.

npm run lint
npm run prettier:check

Running these locally before opening a pull request mirrors what CI will do.

Payments, email and uploads are pluggable, with real switching cost

The template supports Stripe, Polar.sh and Lemon Squeezy for products and payments, and SendGrid, Mailgun or SMTP for email. That choice is presented as a feature, and it is one, but the alternatives are not free to swap. Each provider has its own webhook events, product and price identifiers, and checkout flow. The template abstracts the common shape, and the docs cover integrating services, but moving from one provider to another after you have live subscriptions is a migration project, not a config change.

The same applies to analytics, where Plausible and Google Analytics are both listed, and to deployment, where the one-command path targets Railway or Fly.io while manual deployment to any other host is described as possible. The README does not document what manual deployment involves, so if you need a specific platform, confirm that path in the docs before you build on the assumption.

AI-assisted coding is treated as a first-class integration rather than an afterthought. The repository description mentions a tailored AGENTS.md, skills and a Claude Code plugin, and the README says the template is ready to work with Claude Code, Cursor, Codex and OpenCode. Whether that helps depends on your editor, but the files are part of the template rather than something you add.

Where Open SaaS is the wrong tool

The clearest mismatch is a non-React stack. If your team writes Vue, Svelte or server-rendered templates, the entire front end of this template is dead weight and the Wasp layer will not help you. There is no partial adoption here.

A second mismatch is infrastructure control. The README describes one-command deploy to Railway or Fly.io, and manual deployment to other hosting as an option it does not detail. Teams with strict requirements around container images, Kubernetes manifests or an internal platform will find that the Wasp build and deploy path is the thing they have to work around, not a detail they can ignore.

A third is scope. This is a full SaaS shell: landing page, blog and docs scaffolding, admin dashboard, analytics. If you are building an internal tool with ten users and no billing, you are carrying auth providers, payment integrations and marketing pages you will never configure. Starting from a smaller Wasp template or a bare Wasp app would be less to delete.

Finally, the template is versioned against Wasp releases. The release list shows template tags for Wasp 0.23, 0.24 and 0.25, the most recent on 2026-07-27. That cadence means your copy is tied to a Wasp version, and the docs page on pulling template updates exists precisely because staying current is a merge you perform, not a dependency bump.

How it compares with a hand-rolled Next.js starter

The obvious alternative is a Next.js boilerplate with something like NextAuth, Prisma and Stripe wired by hand. The difference is where the abstraction sits. In a Next.js project, auth, jobs and deployment are separate libraries and services you choose and configure individually, and the framework stays out of your data model configuration. You get more freedom and more decisions.

Open SaaS inverts that. Wasp owns auth, jobs, type inference and deploy, so the template is thin because the framework is thick. The README's claims about a few lines of code for auth and inferred types without third-party libraries only hold because Wasp is doing that work. The trade is straightforward: fewer moving parts to assemble, fewer places to substitute your own.

A second alternative is to use Wasp without Open SaaS. If you want the framework's auth and jobs but not the payments, blog and admin surface, starting from a plain Wasp app and adding only what you need avoids deleting features you never asked for. Open SaaS is the opinionated bundle; Wasp itself is the substrate.

Licence, maintenance and the upgrade tax

The repository is MIT licensed, which permits commercial use, modification and redistribution. The README states the template is free to use and distribute. MIT requires the licence and copyright notice to travel with substantial copies, so keep the LICENSE file in derived projects. This is a description of the licence text, not legal advice; if your organisation has compliance requirements, have counsel confirm how MIT interacts with your distribution model.

On maintenance, the last push to the repository was on 2026-08-06, and the repository is not archived. The release list shows template versions cut for successive Wasp releases, most recently on 2026-07-27. The practical consequence is that upgrades arrive in two layers: Wasp CLI versions and template changes. The README directs readers to the docs for pulling updates to the template, which implies a merge-based workflow rather than an automated one. Budget time for that, especially if you have modified the files the template touches most.

The repository's own tooling reflects this maintenance burden. The tools/ directory exists for maintaining derived projects, and template-test/ exists to test the template itself. Those directories are not part of what you copy, but they indicate the project treats template drift as a problem worth engineering around.

Editorial conclusion

Adopt Open SaaS if you are building a subscription web app on React and NodeJS and want auth, payments, email and background jobs wired before you write product code, and if you accept that Wasp owns the build and deploy path. Skip it if your stack is not React plus Prisma, if you need to run the app as a plain container you control, or if you want a starter you can strip to bare bones without fighting a framework. Before committing, verify the Wasp CLI version your template copy targets, confirm your chosen payment provider is one the template actually supports today, and read the docs page on pulling template updates so you know how you will merge upstream changes into your fork.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wasp-lang/open-saas on GitHub