製品要件を軸に選ぶ
フレームワーク名を比較する前に、製品が必要とするものを書き出します。Web ダッシュボード、オフラインモバイルツール、長いリサーチフローはそれぞれ異なる要件を持ちます。どのクライアントに提供するか、どのデータが各顧客に属するか、タブを閉じた後も続くべき操作は何かを決めます。
機能リストと並んでチームの経験を重みづけします。明確な境界を持つ馴染みのスタックは、認証・デプロイ・永続化の規約を同時に学ぶ必要がある新しい組み合わせより維持しやすいかもしれません。最初のインストールだけでなく、更新とデバッグの継続的な作業を数えてください。
- 初日に必要なクライアント面 — Web のみか、モバイルとデスクトップもか。
- どのデータが各顧客に属するか、チームがワークスペースを共有するか。
- ブラウザタブを超えて存続しなければならない操作：キューされたジョブ、スケジュール処理、長時間実行タスク。
- 何に課金するか — サブスクリプション、シート、使用量 — そして誰が支払うか。
- チームが現実的に運用できる面の広さ：データベース、キュー、プロバイダー。
フレームワークの下の層を評価する
フレームワーク名が説明するのは表面です。その下の層が、製品が一体として保てるかを決めます。一つずつ見ていき、それぞれに同じ質問をします：この決定を所有しているのは誰か、どこで強制されているか？
スタックが空白にしている層は、あなたが引き受ける作業として扱います。「認証は持ち込み」は立派な設計ですが、セッションの意味論・プロバイダー統合・それに続くすべての失敗ケースを自分で所有することを意味するだけです。空白の層は選択ですが、見えない層は負債です。所有されている層が実際どう見えるかは、キットのモジュールドキュメントが良い参照になります。
| 層 | 答えるべき質問 |
|---|---|
| 認証 | すべての面で、誰がセッションを発行し検証するか？ |
| データ | 各レコードはどうやって所有顧客にスコープされるか？ |
| 課金 | 支払いイベントはどこでアクセス権になり、誰が取り消すか？ |
| バックグラウンド処理 | ジョブが失敗・再試行・二重実行したとき何が起きるか？ |
| AI とプロバイダー | キー・モデル選択・支出上限は誰が所有するか？ |
| 運用 | 秘密情報・ログ・バックアップ・アップグレードは実際どう動くか？ |
ツール間の接合部を検査する
スタックとは統合の決定の集合です。誰がセッションを所有するか、レコードがどうスコープされるか、支払いイベントがどこで権限になるか、UI がバックグラウンド処理の結果をどう取り出すかを特定します。これらの接続が、リクエストが失敗したり重複到着したりしたときにハッピーパスが正しいままかを決めます。
supastack は Web 面に Next.js、モバイルに Expo、その下に共有 TypeScript パッケージを使います。Better Auth が認証を所有し、Postgres と Drizzle がレコードを永続化し、Trigger.dev が明示的なワークフロー動作を所有します。これらはリポジトリの選択であり、すべての製品が同じツールを使うべきという主張ではありません — 技術スタックガイドが各選択とその理由を記録しており、違うツールを選んでも質問はそのまま使えます。
どんなツールでも、テストは同じです：レコードを 1 つ選び、インターフェースからサーバー境界を通り、永続化まで、そして戻るまで追跡します。どこかの区間が強制されたルールではなく慣習なら、将来の貢献者がいつかそれを壊します。
動かし続けるコストを数える
スタックの決定は運用の決定でもあります。Postgres にはバックアップとマイグレーションの規律が必要です。ジョブランナーには誰かが実際に開くダッシュボードが必要です。すべてのプロバイダーキーにはローテーションとクライアントバンドル外の居場所が必要です。機能チェックリストに心を奪われる前に、これらの項目を比較に加えてください。
選択肢があるうちにアップグレード経路を確認します。依存が固定され、文書化された更新プロセスを持つモノレポ — キットはまさにそのための更新ガイドを整備しています — は、それぞれ異なるバージョンを前提としたチュートリアルから組み立てたスタックより、年月を経ても健全です。
- 依存関係とセキュリティの更新：どの頻度で届き、誰が適用するか。
- プロバイダー認証情報：どこに置かれ、誰がローテーションできるか。
- データ：バックアップ計画、復元訓練、保持ポリシー。
- 可観測性：何が大きく壊れ、何が顧客の報告まで静かに失敗するか。
小さな垂直スライスを構築する
スタックにコミットする前に、ユーザーをログインさせ、所有レコードを書き、処理を開始し、結果を取り出すスライスを実行します。次に意図的に間違ったワークスペース、期限切れセッション、失敗したジョブを試します。これらの通常の条件がどれだけのカスタムグルーを要するかを評価します。
短い決定記録を残します：スタックがサポートすること、後回しにすること、再検討のトリガー。ネイティブ購入、実プロバイダー受け入れ、デプロイ運用は、成功したローカルビルドの背後に隠れた仮定ではなく明示的な項目であるべきです。正しいスタックは、チームに製品作業へ十分な注意力を残します。
スライスがスターターのリポジトリ内でうまくいったら、次の問いはそれを採用するかどうかです — スターターキットかゼロからかがその決定を順にたどります。
- ログインし、リロード後にセッションを復元する。
- 1 つのワークスペースにスコープされたレコードを書き、読み戻す。
- バックグラウンドタスクを開始し、後で結果を取り出す。
- 間違ったワークスペースと期限切れセッションから同じ呼び出しを繰り返す。
スタック選びについてよくある質問
スタックの決定には自信満々の助言が集まりがちです。代わりに、自分の製品について答える価値のある質問はこれらです。
- すでに知っているスタックを選ぶべきですか？ — 製品の要件を表現できるなら、たいていはイエスです。境界の明確な馴染みのスタックは、何ヶ月もかけて学ぶ流行のスタックに勝ります — ただし製品がネイティブモバイルのような欠けたものを本当に必要とする場合を除きます。
- フロントエンドフレームワークが最重要ですか？ — その周囲の層ほどではありません。フレームワークは UI を形作りますが、認証・スコープ・課金・バックグラウンド処理が製品が正しくあり続けるかを決めます。
- スタック評価にはどのくらいかけるべきですか？ — 数週間ではなく数日です：要件を書き、継ぎ目を検査し、垂直スライスを 1 つ実行する。普通の失敗にカスタムグルーが必要なら、探し続けてください。
- 後からスタックを乗り換えるのが正当化されるのはいつですか？ — 必須プラットフォームやスケールの閾値といった中核の制約が変わったときであって、新しいリリースが良く見えるときではありません。乗り換えコストはコンポーネントではなく認証とデータにあります。