Sushi SaaS が適しているケース

スターターが時間を節約できるのは、そこに組み込まれた判断を採用したい場合だけです。Sushi SaaS は、ユーザー ID、テナント設計、課金、利用量、運用をつなぐソースコードの土台です。これらを理解せずに済ませる仕組みではありません。

Sushi SaaS を選ぶケース

• Next.js、TypeScript、PostgreSQL、Drizzle、Better Auth、Stripe が、採用予定の技術スタックと一致する。
• 顧客が一人またはチームで使い、課金、クレジット、ファイル、タスク、利用上限を組織単位で管理する。
• 金銭と利用量の変更に、冪等性、追記専用の台帳、Webhook の再処理、照合作業が必要である。
• 非公開オブジェクトストレージ、トランザクションメール、アクセス頻度制限、永続ジョブ、翻訳済みエラーを運用する。
• サポート業務に、MFA、読み取り専用・読み書き可能な権限、モデレーション、請求確認、監査を備えた別のコンソールが必要である。
• チームがアーキテクチャの境界と失敗経路のテストを重視し、それらを維持できる。

利点はページ数ではなく、これらの機能が一つのテナントモデルと不変条件を共有していることです。

より小さな選択肢がよいケース

• ランディングページや使い捨ての試作品で需要を検証したい。
• 一人で使う課金なしの製品である、またはホスティング型の ID 基盤やデータベースの方が運用を減らせる。
• 必須のデータベース、フレームワーク、認証事業者、課金モデルが既定の技術スタックと合わない。
• 所有・運用するソースコードではなく、ホスティング型のノーコードサービスが必要である。
• テナント設計やコンプライアンスの仕組みを置き換える費用が、小さく作り始める費用を上回る。

導入戦略を選ぶ

基盤を維持する

大半の境界が合う場合です。ブランドとサンプル機能を置き換え、外部サービスを設定し、自社を差別化する処理を構築します。最短で進められ、更新内容も理解しやすくなります。

不要な機能を完全に削除する

中核アーキテクチャは合うものの、特定の機能領域が不要な場合です。UI、ルート、サービス、モデル、スキーマ、設定、ジョブ、テスト、文書を縦断してまとめて削除します。ナビゲーションだけを隠して、使われないデータ経路を残さないでください。

一つの実装パターンだけを移植する

既存アプリケーションへ取り込む方法です。コードだけでなく、マイグレーション、制約、テスト、運用時の挙動も一緒に移植します。冪等性キーとデータベース規則のないクレジット関数は、同じ実装パターンとはいえません。

別の土台から始める

中核となる技術スタックや所有モデルが異なるなら、別の土台を選ぶのが妥当です。スターターは将来の判断を減らすためのものであり、プロダクト開発の前に大規模な書き直しを生むものであってはいけません。

クローン後も残る作業

外部サービスのアカウントとシークレット、価格、税、返金方針、法務文面、データ保持、バックアップ、復元訓練、監視、アクセシビリティ、脅威の見直し、インシデント対応は自分で担います。テキストから動画を生成するアダプターの置き換えと、予約・紹介機能をプロダクトに含めるかの判断も必要です。

「本番運用を意識している」とは、責任を明示して技術的な制御を提供するという意味であり、デプロイすれば安全だという保証ではありません。

1時間で適合性を確認する

1. クイックスタートを実行し、二つのアプリケーションを開きます。
2. 必須機能を、実在するページとサービスに対応付けます。
3. 技術スタック、組織、課金、クレジット、ストレージ、ジョブ、対応言語、管理機能、紹介機能を維持・変更・削除に分類します。
4. 金銭または認可に関わる処理を一つ追い、そのテストを読みます。
5. 「変更」が多ければ、より小さな出発点を選びます。

続けて Sushi SaaS の構造とデプロイとセキュリティを読んでください。本評価はスターターのコミット 7580470 に基づきます。