複数プロダクトを1台の共有基盤（VPS 等）へ同居させてコストを畳む構成では、「軌道に乗ったら出ていく」前提を設計に織り込む。限界が来る軸を見誤らないことと、卒業コストを安いまま保つことの2点が要点。

判断基準

• 同居構成の限界は技術負荷より先に事業要求水準で来る。静的配信を CDN・ホスティング側（Vercel 等）へ逃がした構成ではトラフィック増は共有基盤に届かず、データも小規模なら数年持つ。一方、有料顧客が付いた瞬間に配信・稼働の信頼性が契約的期待に変わり、同居プロダクトの障害巻き添えや個人水準のバックアップ・監視が許容できなくなる。
• したがって卒業トリガーは負荷メトリクスでなく事業イベントで事前定義する。例:「有料課金者が発生し、月商が専用インフラ費を超えたら専用基盤へ分離する」。検証前のプロダクトに専用固定費を先払いするのは順序逆転で、共有基盤は「軌道に乗るかを検証するインキュベーター」として使う。

卒業手順を安く保つ設計不変条件

• プロダクト別のデータベース・ロール分離: 対象プロダクトの DB だけを dump/restore すれば移設が完結し、同居プロダクトのデータと絡まない。
• 全サービスのコンテナ化: イメージが移設先（専用 VPS・マネージド実行環境）でそのまま動く。
• エッジ層の不変: フロントのホスティングと DNS 構造を移設で変えず、API ドメインの向き先変更だけで切り替わるようにする。

検証

「このプロダクトだけを今すぐ抜けるか」を dump/restore + ドメイン向き先変更の手順で説明できるかを、同居プロダクトが増えるたびに確認する。説明できなくなる変更（DB の相互参照、コンテナ外の暗黙依存、エッジ層の共有基盤依存）が入っていたら不変条件の破れとして扱う。