顧客の最初のセッションを歩く
公開予定の環境で新しいアカウントを作成します。検証やプロバイダーコールバックをたどり、アプリをリロードし、プロフィールを更新し、ログアウトします。狭い画面でキーボードを使ってその行程を繰り返します。いつもの開発セッションは、欠けた設定ステップや古い状態を隠すことがあります。
次に何をすべきかを説明する通知を見直します。空の画面は有用なアクションを提供すべきです。失敗したリクエストは、成功したかのように見せるのではなく再試行方法を説明すべきです。これらの通知には実際の製品言語を使い、アカウントとサポートのリンクが実在の宛先へ行くことを確認します。
ログイン方法ごとにその行程を 1 回ずつ繰り返します。Google と GitHub の OAuth コールバックはそれぞれ独自のリダイレクトと失敗モードを持ち（OAuth セットアップガイドが設定方法をカバーしています）、プロバイダーのテスト用同意画面は本番のものとは動作が異なります。
- アカウント作成とセッション復元が機能する。
- ログアウトがアクセスを取り消し、前ユーザーの表示をクリアする。
- 空・読み込み中・エラー状態がモバイルでも理解できる。
- すべての OAuth プロバイダーが実際のドメインでコールバックを完了する。
- 確認メールとリセットメールが届き、明確に読め、正しい環境へリンクしている。
- 初回実行体験が新しいユーザーに次に何をすべきかを伝える。
サーバーで有料アクセスを証明する
チェックアウトは簡単な半分です。プロバイダーのサンドボックスでライフサイクル全体を歩きます：購入、webhook の受信と検証、権限の永続化、有料機能の解放 — そして更新、解約、返金。すべての遷移はクライアントのフラグではなくサーバー所有の状態を変えるべきです。課金ガイドが supastack がその状態をどこに置くかを示しています。
次に、見たくないイベントをテストします：2 回配信される webhook、失敗した支払い、タスクの途中で失効するサブスクリプション。権限はリクエスト時点で「今これは許可されているか」に答えます — ダッシュボードのバッジは答えません。
- サンドボックス購入が完了し、有料機能を解放する。
- 重複した webhook 配信が安全 — 処理が冪等である。
- 解約と返金がサーバー境界でアクセスを取り消す。
- シートごと・使用量上限があるなら、条件を超えた分を拒否する。
実際の依存関係で境界を検証する
2 つの独立したアカウントで所有権を検証します。一方から他方のレコードの読み取りと変更を試みます — タスク状態や復旧 URL を含めて。インターフェースのボタンを隠すだけでなく、サーバーアクション境界で有料アクセスを検証します。
ワークスペースにスコープされたレコードはマルチテナント製品の背骨です — ワークスペース境界の記事がそのモデルを説明しています。どんなスタックでも、ローンチの問いは同じです：すべての読み書きがサーバーの認証済みコンテキストから所有権を導出し、レコード ID やクライアント送信のワークスペースを証拠として受け入れていないか？
- ワークスペース間の読み書きが拒否される。
- 復旧 URL とタスク URL がそれ自体ではアクセスを許可しない。
- リストと詳細ビューが同じスコープを強制する。
- API キーと webhook があるなら、それらもワークスペーススコープを持つ。
失敗経路をわざと実行する
バックグラウンド処理は 2 つの異なる形で失敗し、それぞれ独自のテストが必要です。ディスパッチの失敗は、キューに入ったかどうかクライアントを不確かにします — タスクスコープの冪等性キーと保存された送信があれば、複製ではなく元のリクエストを復旧に再利用できます。完了の失敗は、処理は走ったが結果が届かなかったことを意味します — 再試行と状態ポーリングが二度目の生成なしにその隙間を埋めるべきです。
同じ考え方をプロバイダーにも適用します：AI プロバイダーのタイムアウト、バウンスしたメール、課金 API エラー。それぞれが静かな半分の結果ではなく、具体的で説明可能な状態で終わるべきです。タスク復旧ガイドがキットの本番経路がこれをどう処理するかを文書化しています。
- 送信タイムアウト後の再試行が作業やコストを重複させない。
- 失敗した完了が見えて回復可能であり、静かな損失ではない。
- プロバイダーエラーが汎用的なクラッシュではなく誠実な状態としてユーザーに届く。
最初の障害に備える
誰かがエラーを見つけ、影響を受けたタスクに関連付け、プロバイダーの秘密を晒さずにユーザーの復旧を助けられるようにします。どのログと監査レコードが存在し、どれだけ保持し、運営者がどうアクセスするかを確認します。
ローンチ前に「何かがおかしい」がどう見えるかを決めます：失敗したジョブ配信、webhook 検証エラー、プロバイダー支出の急な上昇。誰も受け取らないアラートは監視ではありません — 可観測性セットアップがそれらの信号の配線をカバーしています。
バックアップは運用演習として扱います：設定済みのバックアップと復元済みのバックアップは同じではありません。必要になる日が来る前に、本番に似たデータで一度復元を実行してください。
- エラーがそれを引き起こしたリクエスト・ユーザー・タスクまで追跡できる。
- ログと監査レコードにオーナー・保持ポリシー・アクセスルールがある。
- バックアップが設定されただけでなく復元されている。
- 失敗したジョブと webhook エラーが人が受け取るアラートを上げる。
製品の周囲の面を確認する
法務とコミュニケーションの面は、仕上げではなくローンチの一部です：製品が実際にやることを記述したプライバシーと利用規約、人に届くサポートアドレス、そしてトランザクションメールがあなたの所有するアドレスから届くようにする検証済み送信ドメイン。
すべての自動メールを顧客として読んでください。確認・リセット・レシート・完了メッセージには、製品名・正しい環境へのリンク・そして死んだ noreply アドレスではない返信経路が必要です。
- プライバシーと利用規約ページが実際に運営する製品を記述している。
- トランザクションメールが所有する検証済みドメインから送信される。
- サポートと課金の質問に届く宛先がある。
Go / No-Go の決定を明示する
リリース記録をまとめます：ビルドリビジョン、ターゲット環境、何をどうテストしたか、何が未検証のままか。正直なギャップのあるチェックリストは自信満々の要約に勝ります — 最初のインシデントはたいていそのギャップに住んでいます。
必要になる前にロールバック経路を決めます：デプロイをどう戻すか、その間に書き込まれたデータをどうするか、誰が判断するか。そして完全にサポートできる最小の提供形態でローンチし、意図的に広げていきます。
ローンチについてよくある質問
ローンチチェックリストは予測可能な場所で失敗します。それらのほとんどを捕まえる質問はこれらです。
- ほとんどの SaaS ローンチが忘れているものは？ — フローの終わりです：実際に取り消すログアウト、実際にアクセスを外す解約、紙の上に存在するバックアップの復元訓練。
- テストアカウントはいくつ必要ですか？ — ターゲット環境で少なくとも 2 つ。データ分離と招待フローは 1 つでは検証できません。
- サンドボックステストと本番テスト、どちらをすべきですか？ — 両方です。サンドボックスはライフサイクルの論理を証明し、小さな実取引はキー・ドメイン・webhook が正しい場所に配線されていることを証明します。
- ローンチしてよいのはいつですか？ — 顧客データやお金を守るすべての項目が検証され、未検証の項目がオーナー付きで書き留められたときです — 機能リストが完成に見えたときではありません。
- ローンチ後に何が変わりますか？ — リリース記録を保持し、設定した失敗アラートを監視し、認証・課金・スコープへの重要な変更後にチェックリストを再実行します。