When Sushi SaaS Is a Good Fit

A starter saves time only when you want its decisions. Sushi SaaS is a source-code backbone for teams that need connected identity, tenancy, billing, usage, and operations—not a shortcut around understanding those systems.

Choose Sushi SaaS when

• Next.js, TypeScript, PostgreSQL, Drizzle, Better Auth, and Stripe match your intended stack.
• Customers may work alone or in teams, while billing, credits, files, tasks, and limits belong to an organization.
• Money and usage changes need idempotency, immutable ledger entries, webhook replay handling, and reconciliation.
• You expect to operate private object storage, transactional email, rate limits, durable jobs, and localized user errors.
• You want the local developer loop, migration policy, observability, backups, restore drills, containers, and launch audit to be part of the starter rather than a post-launch rescue project.
• Support staff need a separately deployed console with MFA, read/write roles, moderation, billing inspection, and audit records.
• Your team values enforced boundaries and failure-path tests enough to maintain them.

The benefit is not the number of pages. It is that these systems share one tenant model and one set of invariants.

Choose something smaller when

• You are testing demand with a landing page or throwaway prototype.
• The product is single-user, has no billing, or can use a hosted identity-and-database platform with less custom operation.
• Your required database, framework, identity provider, or billing model conflicts with the shipped stack.
• You need a hosted no-code product rather than code your team owns.
• Replacing the tenancy or compliance model would cost more than building on a narrower base.

Pick an adoption strategy

Keep the backbone

Best when most boundaries fit. Replace branding and example domains, configure providers, and build your differentiated workflow on top. This gives the fastest path while keeping upgrades understandable.

Remove complete capabilities

Valid when the core architecture fits but a domain does not. Remove a feature vertically—UI, routes, services, models, schema, config, jobs, tests, and docs—rather than hiding its navigation and leaving an unowned data path.

Copy one pattern

Useful for an existing application. Bring the migrations, constraints, tests, and operational behavior with the code. A credit function without its idempotency key and database rule is not the same pattern.

Start elsewhere

The right answer when the core stack or ownership model differs. Using a starter should reduce future decisions, not create a long rewrite before product work starts.

Cost that remains after cloning

You still own provider accounts, secrets, prices, tax and refund policy, legal copy, data retention, monitoring, accessibility, threat review, and incident response. Replace the image/video mock providers, decide whether Content Studio, marketing, reservations, and referrals belong in your product, and set real recovery targets. The starter supplies controls; it cannot make those business decisions.

“Production-minded” means the repository exposes these responsibilities and supplies technical controls; it does not certify your deployment.

A one-hour fit check

1. Run Quick Start and open both applications.
2. Map your must-have capabilities to the repository's actual pages and services.
3. Mark each major decision keep, change, or remove: stack, organizations, billing, credits, storage, jobs, locales, admin, and referrals.
4. Trace one money or authorization flow and read its tests.
5. Estimate the “change” column. If it dominates, choose a smaller starting point.

Then read How Sushi SaaS Is Structured and Deployment and Security. This assessment reflects starter commit 2a1a04a.