Sushi SaaS 是什么
了解这个 starter 包含什么、已经替你做了哪些产品决策，以及应该采用全部还是部分能力。
Sushi SaaS 是一个采用 MIT 许可、面向订阅制和按量计费产品的源码 starter。它不是托管平台，也不会根据表单自动生成应用。你需要克隆仓库、拥有并维护代码，再根据自己的用户调整其中的产品决策。
文档还是指南？
当任务已经明确，需要针对当前代码执行配置、扩展、验证或运维时，请使用文档。当你需要判断某项默认选择是否适合、理解选择原因，或决定保留、修改、移除什么时，请使用指南。它们服务于同一采用流程中的不同阶段。
适合谁评估
如果你是开发者或小型工程团队，并且已经倾向使用 Next.js、TypeScript、PostgreSQL、Drizzle、Better Auth 和 Stripe，可以评估 Sushi SaaS。当产品还需要组织、多成员共享积分、私有上传、后台任务、多语言 UI 和运营后台时，它的价值最高。
如果你只是在验证落地页、构建无计费的单用户工具，或准备替换上述大部分技术栈，应选择更小的基础。删除从未需要过的契约，通常比从一开始少引入一些更昂贵。
仓库里有什么
仓库包含三个可独立部署的应用和一个可移植 Worker：
src/app客户应用，包括认证、组织、计费、积分、私有存储、预约和付费任务参考；apps/admin独立管理应用，包括 MFA、读写角色、任务恢复、风控、对账、账单与审计；apps/content-studio独立 Payload 创作和活动应用，拥有自己的数据库与编辑认证；- 可在 VM/容器旁运行或通过调度路径执行的持久 Worker。
Web 与 Admin 共享 SaaS schema 和认证数据，Content Studio 绝不共享；客户身份、同意和投递审计留在 SaaS。公开网站是第四个独立仓库，使产品指导不与应用发布耦合。
你会继承的决策
| 默认选择 | 选择它的原因 | 何时重新考虑 |
|---|---|---|
| 路由 → 服务 → 模型 → 数据库的水平分层 | 让业务规则和查询各自只有一个明确位置 | 团队已确定另一种架构，并准备同步修改约束测试 |
| 每个账户拥有或加入一个组织 | 让计费、文件、积分和限额共享一个租户边界 | 产品确定只会单租户，并愿意完整移除组织作用域 |
| 由 Stripe 事件最终确认计费状态 | 把重试和延迟 webhook 视为正常输入 | 使用不同计费供应商或商业模型 |
| 管理后台独立部署 | 把运营入口与客户导航隔离 | 运营足够简单，可以明确合并应用与部署边界 |
| 五种产品语言 | 让界面文案和错误都可本地化 | 只支持部分语言，并同时移除对应路由、目录与测试 |
这些是默认值，并不表示所有 SaaS 都应做同样选择。
三种采用方式
- 保留完整骨架。 保持边界，替换品牌和示例产品界面，再配置 provider 与业务政策。
- 采用部分模式。 复制一项完整能力，例如积分台账或 Stripe 重放处理，并同时带上 migration、测试和运维规则。
- 只把它当作参考。 对照自己的系统检查失败处理和不变量，不必引入代码。
不要留下“两套架构”或“两种租户模型”的半迁移状态，否则每次修改都会出现两个看似正确的位置。
仍由你负责的部分
Starter 无法替你决定价格、退款政策、数据保留、法律条款、客服流程、备份目标、反欺诈措施或威胁模型。推荐奖励默认关闭，因为打款规则同时涉及业务和合规。示例文生视频 provider 与预约流程也是集成示例，而不是完整的产品定位。
一次实际评估
- 按快速开始运行客户应用、管理后台、Content Studio 和 Worker。
- 选择一个真实需要的流程——注册、Checkout、上传或积分消费——从路由追到数据库。
- 阅读什么情况下 Sushi SaaS 适合你，列出准备保留、修改和删除的默认决策。
- 在估算生产工作前阅读部署与安全。