Open SaaS (wasp-lang/open-saas): a free Wasp-based SaaS boilerplate with AI agent rules

What Open SaaS is and the problem it removes

Starting a paid web product means writing the same non-differentiating code before you write anything a customer would notice: signup, email verification, OAuth callbacks, a Stripe webhook handler, a password reset mailer, a cron job that sends a digest, an S3 upload endpoint, and an admin view. Open SaaS ships that layer as a template rather than a library. The README describes it as a template that is fully open-source, completely free to use and distribute, and ready to work with AI coding tools and agents.

The intended user is a small team or solo developer who has picked React for the front end and Node with Prisma for the back end and does not want to spend the first month on plumbing. The repository is organised around that assumption: the template lives in template/, the live demo site in opensaas-sh/, a separate test fixture in template-test/, and shared maintenance scripts in tools/. The README points readers at opensaas.sh for a running example and docs.opensaas.sh for the written documentation.

It is not a hosted service and not a set of npm packages you import into an existing app. You copy it. That distinction matters later, when you want upstream fixes.

How Wasp drives the template's architecture

The mechanism is that Open SaaS is not a standalone Node application with its own server entry point. It is a Wasp project, and Wasp is the framework that generates and runs the client, the server and the database migrations. The README lists what that buys the template: full-stack authentication with email verification and social providers in a few lines of code, end-to-end type safety where backend function types are inferred on the front end without third-party libraries, background jobs defined as functions in the config file, and one-command deploy.

That config-file-as-source-of-truth model is the part to understand before adopting. Routes, auth methods, jobs and deployment settings live in Wasp's declarative configuration rather than in ordinary application code. The payoff is that type inference and job scheduling come for free. The cost is that a large part of your application's shape is expressed in a DSL you have to learn, and generic Node advice you find online will not always map onto it.

Around that core, the template assembles a conventional stack. ShadCN UI for components and styling, with an admin dashboard. Stripe, Polar.sh or Lemon Squeezy for products and payments. SendGrid, Mailgun or SMTP for email. AWS S3 for uploads. Plausible or Google Analytics. An OpenAI API example that demonstrates function calling. Playwright for end-to-end tests. Astro's Starlight template backs the documentation and blog.

Installing Open SaaS and running your first app

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

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

Then scaffold a new project from the template. The README states this creates a clean copy of the Open SaaS template into a new directory:

wasp new -t saas

After that, the README defers to docs.opensaas.sh for everything else, saying installation instructions, pulling updates, service integrations, SEO and deployment are documented there in detail. It does not reproduce the database setup, the environment variables for Stripe and S3, or the development start command in the README itself, so treat the docs site as required reading rather than optional.

The repository also carries its own formatting and linting scripts, which run in CI. If you contribute back or want the same checks locally, the root package.json defines them:

npm run prettier:check
npm run lint

Both Prettier and ESLint checks are described as running automatically in CI/CD pipelines.

Where Open SaaS is the wrong tool

The clearest limitation is the framework coupling. Every feature in the template is expressed through Wasp, so leaving Wasp later means rewriting the parts that make the template valuable: auth wiring, job definitions, route configuration and deploy. If your team has already standardised on a plain Express or Next.js backend, adopting Open SaaS means adopting a second framework and a config language on top of it.

Second, the template is a copy, not a dependency. The README's detailed instructions section mentions pulling updates to the template, which implies the project has thought about the upgrade path, but the README itself does not document how conflicts between your changes and upstream are resolved. The release history shows why this matters: separate tags exist for Wasp 0.23, 0.24 and 0.25 templates, published on 2026-05-29, 2026-06-11 and 2026-07-27. Upstream moves with the framework, and your fork does not move with it automatically.

Third, the provider list is a menu, not a guarantee. Payments support Stripe, Polar.sh and Lemon Squeezy; email supports SendGrid, Mailgun or SMTP. If your billing provider is not on that list, you are writing the integration yourself, and the template's value drops accordingly. The same applies to hosting: the documented one-command deploy targets Railway and Fly.io, with manual deployment to other services described as possible but not automated.

Open SaaS compared with assembling your own starter

The realistic alternative is not another boilerplate. It is building the same layer yourself from a plain React and Node project, or from a hosted auth and billing product that handles signup and subscriptions as a service. The difference in approach is where the integration work sits. With Open SaaS, the integrations are already written against Wasp's primitives and live in your repository, so you can read and modify every line, but you inherit the framework. With a hosted auth and billing provider, you keep your own framework and lose direct control over the auth and subscription data model, and you take on a recurring dependency.

A second alternative is to start from Wasp's own scaffolding without the SaaS features. The README notes that wasp new -t saas produces the Open SaaS template specifically, which implies other templates exist; choosing a leaner one leaves you writing auth and payments yourself but removes the parts of Open SaaS you would have deleted anyway.

The trade-off is legible: Open SaaS optimises for time-to-first-customer, and pays for it with framework lock-in and a copy-based upgrade path. If neither of those costs bothers you, the template is doing real work on your behalf.

Maintenance, licence and what an upgrade costs

The repository is not archived, and the last push was on 2026-08-06. The most recent release is the wasp-v0.25-template tag from 2026-07-27, following wasp-v0.24-template on 2026-06-11 and wasp-v0.23-template on 2026-05-29. Those tags are the upgrade signal: each one tracks a Wasp release, so the cadence of template releases is set by the framework's cadence, not by the template maintainers' own roadmap.

Practically, that means your upgrade cost is tied to how far your Wasp CLI version has drifted from the template tag you copied. The README does not document rollback, nor does it describe what happens when a Wasp major version changes behaviour your customisations depend on. Budget for reading the Wasp release notes alongside the template tag diff.

The licence is MIT. That permits commercial use, modification and redistribution, and the README reinforces that the template is completely free to use and distribute. The practical implication for a closed-source product is that you can keep your fork private. The MIT terms also mean no warranty and no support obligation from the maintainers; help is routed through GitHub issues and the Wasp Discord, where the README asks that questions go to the #questions forum channel. This is a description of the licence text, not legal advice.

Editorial conclusion

Adopt Open SaaS if you are willing to build on Wasp and want auth, payments, email, background jobs and uploads wired before you write product code. Do not adopt it if you need to own every layer of the stack, if you already have a working Node and Prisma backend, or if you cannot accept a framework-specific config file as the source of truth for routes, jobs and auth. Before committing, verify three things: that the Wasp CLI version you install matches the template tag you clone, that your chosen payment provider is one of the ones the template actually integrates, and that the deploy target you plan to use is covered by the documented one-command deploy path.

Frequently asked questions

Official sources

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