Sushi SaaS とは
スターターに含まれるもの、採用済みのプロダクト判断、全体または一部を導入する判断基準を説明します。
Sushi SaaS は、サブスクリプション型・従量課金型プロダクト向けの MIT ライセンスのソースコードスターターです。ホスティングサービスでも、フォームからアプリを生成するツールでもありません。リポジトリをクローンし、コードを所有・運用しながら、組み込まれた判断を自社ユーザーに合わせて変えていきます。
ドキュメントとガイドの使い分け
ドキュメントは、機能を設定・拡張・検証・運用するための具体的な手順です。ガイドは、なぜその設計を選んだのかを理解し、自社製品で何を維持・変更・削除するかを判断するための読み物です。実装するときはドキュメントを、方針を決めるときはガイドを起点にしてください。
想定する利用者
Next.js、TypeScript、PostgreSQL、Drizzle、Better Auth、Stripe を採用予定の開発者や小規模チームに向いています。組織、共有クレジット、非公開アップロード、バックグラウンドジョブ、多言語 UI、運用コンソールも必要なら、より多くの土台をそのまま利用できます。
ランディングページの検証、課金のない単一ユーザーツール、または大半のスタックを置き換える予定なら、もっと小さな土台を選ぶ方が合理的です。不要な契約を後から削るより、最初から少なく始める方が安価です。
含まれるアプリ
リポジトリには 3 つの独立 deploy app と portable worker があります。
src/app：auth、組織、課金、credit、private storage、予約、paid task referenceapps/admin：MFA、role、job 復旧、moderation、reconciliation、課金、auditapps/content-studio：独自 DB と editor auth を持つ Payload authoring/campaign app- VM/container または scheduler で動く durable worker
Web と admin は SaaS schema/auth を共有しますが Content Studio は共有しません。Customer identity、consent、delivery audit は SaaS に残ります。公開 site は 4 番目の独立 repository です。
引き継ぐ設計判断
| 既定の選択 | 選んだ理由 | 見直す場面 |
|---|---|---|
| ルート → サービス → モデル → データベースの水平レイヤー | 業務ルールとクエリの置き場所を一意にする | チームが別のアーキテクチャを採用し、強制テストも更新する場合 |
| 全アカウントが組織を所有または参加 | 課金、ファイル、クレジット、上限に一つのテナント境界を与える | 本当に単一テナントで、組織の範囲を全レイヤーから除く場合 |
| Stripe のイベントで課金状態を確定 | 再試行や遅延した Webhook を通常の入力として扱う | 課金事業者や商流が異なる場合 |
| 管理アプリを別デプロイ | 運用アクセスを顧客ナビゲーションから分離 | 一つのアプリとデプロイ境界で十分な場合 |
| 五つの対応言語 | UI とユーザー向けエラーを翻訳可能にする | 対応言語を減らし、ルート、カタログ、テストを一緒に削除する場合 |
これらは初期値であり、すべての SaaS に正しいという主張ではありません。
三つの導入方法
- 基盤全体を使う。 境界を保ち、ブランドとサンプル画面を置き換え、外部サービスと運用方針を設定します。
- 特定の実装パターンだけ使う。 クレジット台帳や Stripe の再処理対応を、マイグレーション、テスト、運用ルールごと移植します。
- リファレンスとして使う。 コードを採用せず、自社システムの失敗処理や不変条件と比較します。
二つのアーキテクチャやテナントモデルが共存する中途半端な移行は避けてください。新しい変更の置き場所が毎回二つになります。
導入後も自分で決めること
価格、返金、データ保持、法務文面、サポート手順、バックアップ目標、不正対策、脅威モデルは、スターター側では決められません。紹介報酬は、支払いに事業上・コンプライアンス上の判断が伴うため、既定では無効です。テキストから動画を生成する外部サービスと予約の流れも統合例であり、完成したプロダクト企画ではありません。
実際に評価する
- クイックスタートで client、admin、Content Studio、worker を開きます。
- 必要な一つの処理（登録、Checkout、アップロード、クレジット消費）を、ルートからデータベースまで追います。
- Sushi SaaS が適しているケースを読み、各判断を「維持・変更・削除」に分けます。
- 本番工数を見積もる前にデプロイとセキュリティを確認します。