Sushi SaaS が適しているケース

Sushi SaaS が有効なのは、スターターが解決する難しい判断と、製品がすでに必要としている判断が重なるときです。基盤の大半を削除する予定なら、節約できる時間は多くありません。

適しているケース

• チームが Next.js、TypeScript、PostgreSQL、Drizzle、Better Auth、Stripe を選んでいる。
• 顧客が個人または共有組織に属し、課金、クレジット、ストレージ、上限が同じ tenant 境界に従う。
• お金と利用量の変更に、冪等性、監査可能なクレジット台帳、照合経路が必要。
• 非公開 S3 upload、永続 DB job、トランザクションメール、多言語エラーが必要。
• 運用担当者に、MFA、読み書きロール、モデレーション、課金確認、監査を備えた別管理コンソールが必要。
• 正常 UI だけでなく、アーキテクチャ、認証ゲート、再実行動作を強制するテストを重視する。

全体像は Sushi SaaS の構造、導入はクイックスタートを参照してください。

適していない可能性が高いケース

• 静的サイト、単一ユーザーツール、アカウントや課金が不要な試作を作る。
• 必須の技術スタックやデプロイ方式が Next.js と PostgreSQL に合わない。
• 所有するソースコードではなく、ホスト済み no-code 製品が必要。
• テナント、課金、コンプライアンスが特殊で、付属契約の置換が小さく始めるより高くつく。

「本番志向」が意味しないこと

スターターが提供するのは制御であり、本番方針ではありません。プランと価格の決定、provider 設定、製品固有の法的文書、バックアップと復旧、配信監視、脅威レビューは必要です。紹介報酬は事業・支払いルールを決めるまで無効です。サンプルのタスク provider とデモ画面にも製品開発が必要です。

機能一覧だけで判断せず、まずローカル環境を動かしてコードを読んでください。その後デプロイとセキュリティを確認し、運用しないドメインを削除します。

この評価は顧客アプリと独立管理アプリを含む starter commit 7580470 に基づきます。