製品作業と繰り返されるインフラを分ける
製品を有用にする機能を列挙し、次にそれを動かすのに必要なインフラを列挙します。リサーチフローは特有かもしれませんが、セッション管理、顧客所有レコード、サブスクリプションアクセスは通常そうではありません。この棚卸しは、スターターのページで機能を数えるより良い評価ツールです。
2 番目のリストは見た目より長いです。ほとんどの SaaS 製品は同じ十数個の部品を再実装しており、それぞれが他と正しく統合されるまで製品は何もできません。
ゼロから構築するとこれらの選択を直接制御できますが、統合と保守の責任も負います。スターターは出発点を変えます。そのコードを理解し、製品・チーム・デプロイについての仮定を検証する必要は残ります。
- 認証：ログイン方法、セッション、アカウント復旧。
- ワークスペース：レコード所有権、招待、メンバーロール。
- 課金：チェックアウト、webhook、権限、解約。
- バックグラウンド処理：キュー、再試行、スケジュール、状態追跡。
- 配信：トランザクションメール、ファイルストレージ、デプロイ。
値札ではなく総コストを比較する
スターターの価格は見えますが、ゼロからのコストは数ヶ月に分散します。正直に集計してください：認証・課金・ジョブ・デプロイの組み立てに費やす週、それらの組み立てに付いてくる統合バグ、そしてその後プロバイダー更新のたびに発生する保守。
スターターのコストは、自分が書いていないコードを学び適応させることです：規約を読み、サンプルコンテンツを置き換え、時には引かれた境界を少し曲げる。以下の検査がうまくいくなら、その交換はたいてい同じ配管を作り直すより安く済みます。うまくいかないなら、それは無視すべきでない警告です — 今日読めない境界は来年の本番障害です。
継承するコードを評価する
インストール手順を実行し、レコードをインターフェースから永続化まで追います。認可がサーバー境界にあるか、設定が検証されるか、プロバイダー認証情報がクライアントバンドル外に保たれるかを確認します。デモ画面だけでなく、ネガティブテストを読んでください。
サンプル製品がインフラと切り離せなくなっている箇所を探します。デモ機能を外すのに認証や課金の振る舞いを変える必要があるなら、将来の製品作業は最初のインストールが示唆するより難しいかもしれません。supastack では、消費製品はドメインロジックを Starter Core の外に置き、設定とコントラクトを通じて接続します — プロジェクト構成ガイドがその線の位置を示しています。
- 自分で解明しなければならなかった、文書化されていないセットアップ手順のすべて。
- 認可がどこで強制されているか、ルートごとか体系的か。
- ネガティブテスト — ワークスペース間読み取り、リプレイされた webhook — が存在するか、それが何を証明するか。
- 秘密情報がどこにあり、クライアントバンドルに届くものがあるか。
- デモ機能を削除しようとしたとき、インフラに何が起きるか。
決める前に動かす
コミットする前に、リポジトリの中で 1 日過ごしてください。supastack なら corepack pnpm install、設定済みの apps/web/.env.local、そしてローカル参照フロー：ログインし、アクセスを検査し、タスクを送信し、結果を読みます。その後 pnpm verify:local が認証情報なしで fake プロバイダーに対してゴールデンパスを実行します — ローカルセットアップガイドが一連の流れを案内します。
次に、わざと何かを壊します。同じタスクを 2 回送信する。間違ったワークスペースで API ルートを呼ぶ。webhook をリプレイする。普通の失敗を優雅に処理するスターターは、機能リストが長いものより価値があります — 自分のマシンでクリーンに失敗させられないものは、いずれ本番でデバッグすることになるからです。
トレードオフを明示する
スターターの既存の境界がニーズに合い、依存する流れを説明できるならスターターを選びます。製品要件がスターターの仮定への繰り返しの変更を強いるなら、特注の基盤を選びます。どちらも合理的な選択です。重要な問いは、チームがどの保守負荷を担えるかです。
サンプルコンテンツの置き換え、統合の設定、データ所有権のレビュー、デプロイのテストに時間を確保します。コンパイルできるリポジトリは本番受け入れの出発点です。ローンチ前に、実際のログイン経路、課金ライフサイクル、復旧の振る舞いを顧客が使う環境で検証してください — ローンチチェックリストに列挙されています。基盤となるスタックも未決定なら、SaaS スタックの選び方が層ごとの評価をカバーしています。2 つの決定は互いに影響し合います。
| ゼロから構築 | スターターキットを採用 | |
|---|---|---|
| あなたが所有するもの | すべての規約・統合・失敗モード | 製品コード。配管は保守済みで来る |
| 初期の速さ | 遅い — まず配管から | 速い — 初日から機能作業 |
| リスクの居場所 | まだ見つけていない継ぎ目 | まだ検査していない境界 |
| 正しい選択になるとき | あなたの制約が典型の想定を壊すとき | その境界が製品のニーズに合うとき |
スターターキットについてよくある質問
買うか作るかの議論は強い意見を生みがちです。実際に決定を動かす質問はこれらです。
- 本気の製品にスターターキットを使うのは危険ですか？ — 多くの本番 SaaS が購入した基盤の上で動いています。リスクはスターターではなく、検査していないコードを継承することです。依存する前に境界を読んでください。
- ボイラープレートが保守されているかどう見分けますか？ — 最近のコミット、文書化された更新経路、失敗ケースを実行するテスト、ロードマップの約束ではなく具体で返された issue を見てください。
- スターターの選択が自分のものと合わない場合は？ — 好みと制約を区別してください。UI の張り替えは安いですが、セッションモデルやテナント境界と闘うのは高くつきます。構造的なミスマッチは自作する理由になります。
- 後でスターターから離れられますか？ — コードはあなたのものなので、移行して離れる相手はありません — 本当の問いは、変更していってもその配管が資産であり続けるかです。だからこそ製品コードとインフラコードが分離できることが重要です。
- スターターは実際どれくらい時間を節約しますか？ — 認証・課金・ジョブ・デプロイにかかったはずの週数から、継承したものを学び適応させるのに必要な日数を引いた程度です。