What Sushi SaaS Is
What the starter includes, which product decisions it makes, and how to decide whether to adopt all or part of it.
Sushi SaaS is an MIT-licensed source-code starter for subscription and usage-based products. It is not a hosted platform and it does not generate an application from a form. You clone the repository, own the resulting code, and adapt its product decisions to your users.
Docs or Guides?
Use Docs when you know the task and need exact setup, extension, verification, or operating steps for the released code. Use Guides when you are deciding whether a shipped choice fits, why Sushi made it, and what to keep, change, or remove. The two sections serve different moments in the same adoption journey.
Who it is for
Evaluate Sushi SaaS if you are a developer or small engineering team already leaning toward Next.js, TypeScript, PostgreSQL, Drizzle, Better Auth, and Stripe. It is most useful when your product also needs organizations, pooled credits, private uploads, background jobs, localized UI, and an operator console.
Choose a smaller foundation if you are validating a landing page, building a single-user tool without billing, or expect to replace most of that stack. Starting with fewer contracts is cheaper than deleting contracts you never wanted.
What ships
The repository contains three independently deployable applications plus a portable worker:
- the customer application under
src/app, with authentication, organizations, billing, credits, private storage, reservations, and reference paid tasks; - a separate admin application under
apps/admin, with mandatory MFA, read-only/read-write roles, job recovery, moderation, reconciliation, billing inspection, and audit records; apps/content-studio, a separate Payload authoring and campaign application with its own database and editor authentication;- a dedicated durable worker that can run beside containers/VMs or through the bounded scheduler path.
Web and admin share the SaaS PostgreSQL schema and authentication data. Content Studio never does: customer identity, consent, and delivery audit remain in the SaaS. The public website is a fourth, detached repository so product guidance can evolve without coupling application releases to publishing.
Decisions you inherit
| Shipped choice | Why it was chosen | Revisit it when |
|---|---|---|
| Horizontal route → service → model → database layers | Keeps business rules and queries in predictable places | Your team has committed to another architecture and is prepared to update its enforcement tests |
| Every account owns or joins an organization | Gives billing, files, credits, and limits one tenant boundary | Your product is genuinely single-tenant and you are willing to remove organization scoping end to end |
| Stripe events finalize billing state | Makes retries and delayed webhooks normal inputs | Your billing provider or commercial model is different |
| Separate admin deployment | Isolates operator access from customer navigation | Your operations are simple enough to share one application and one deployment boundary |
| Five product locales | Makes user-visible copy and errors localizable | You support fewer locales and remove their routes, catalogs, and tests together |
These are defaults, not claims that every SaaS should make the same choices.
Three ways to adopt it
- Use the full backbone. Keep the boundaries, replace the brand and example product surface, then configure providers and policies.
- Use selected patterns. Copy a self-contained idea—such as the credit ledger or Stripe replay handling—along with its migrations, tests, and operational rules.
- Use it as a reference. Compare its failure handling and invariants with your own system without adopting the code.
Avoid a half-migration where two architectures or two tenant models coexist. That creates two correct-looking places for every new change.
What remains your responsibility
The starter cannot choose your prices, refund policy, data retention, legal terms, support process, backup targets, fraud controls, or threat model. Referral rewards are disabled because a payout policy is a business and compliance decision. The example text-to-video provider and reservation flow are integration examples, not a finished product proposition.
A practical evaluation
- Follow Quick Start and open the customer app, admin console, Content Studio, and worker.
- Trace one real flow you need—signup, Checkout, upload, or credit spend—from route to database.
- Read When Sushi SaaS Is a Good Fit and list the shipped decisions you would keep, change, or remove.
- Review Deployment and Security before estimating production work.
Source: Sushi SaaS starter at commit 2a1a04a.