diff --git a/docs/bitvid-bridge-plan.md b/docs/bitvid-bridge-plan.md
index 95138a3c..32fce4c1 100644
--- a/docs/bitvid-bridge-plan.md
+++ b/docs/bitvid-bridge-plan.md
@@ -5,11 +5,23 @@ Companion to **`docs/live-publish-plan.md`** (#16c) — this expands its **Phase
 gap a static web client can't: **receiving and routing live media** on the
 creator's machine.
 Status: **FUTURE / exploratory — all design decisions LOCKED** (maintainer
-accepted every recommendation). Sequenced after the #16c Media Node MVP; the
-Bridge and the server-side Media Node share one codebase (DECISION 7).
+accepted every recommendation), but **DELIBERATELY DEFERRED** — see the priority
+principle below.
 
-Goal (maintainer): a **super-simple, easy-to-install, easy-to-use** cross-platform
-app (Windows / macOS / Linux) that makes going live on bitvid turnkey.
+> **⛔ PRIORITY PRINCIPLE — static bitvid first (maintainer).** Put as much effort
+> into the **static bitvid client** as possible before branching into any *separate
+> application*. The Bridge is a second app (own repo, toolchain, cross-platform
+> packaging, code-signing cost), so **do not start it** until the static client's
+> live features have shipped and are maximally developed — specifically the Go-Live
+> **Tier-1/2 MVP** (external-provider + serverless, zero infra; see the publish
+> plan's provider spectrum). Rule of thumb: **exhaust what the static client can do
+> before writing a second app.** Build the Bridge only once live has shipped *and*
+> shown real demand for the sovereignty/power features it adds (local recording +
+> full-WebTorrent VOD, no-third-party, multi-restream, hardware/appliance, capture).
+
+Goal (maintainer, *when it's time*): a **super-simple, easy-to-install,
+easy-to-use** cross-platform app (Windows / macOS / Linux) that makes going live on
+bitvid turnkey.
 
 ---
 
diff --git a/docs/live-publish-plan.md b/docs/live-publish-plan.md
index fa6159ea..ebc0bb1b 100644
--- a/docs/live-publish-plan.md
+++ b/docs/live-publish-plan.md
@@ -336,6 +336,35 @@ has enough concurrent viewers — see the ingest plan + Advantages above. The en
 
 ---
 
+## Build order & the static-first principle
+
+> **PRIORITY (maintainer): pour effort into the static bitvid client before
+> branching into any separate app.** Everything through the Go-Live MVP below lives
+> **entirely in the static client** — no Bridge, no VPS, no bitvid infra. The
+> Bridge (a second application) is deliberately deferred until this is shipped and
+> maximally developed. See `docs/bitvid-bridge-plan.md`.
+
+Recommended sequence across the live/short work:
+
+```
+1. Shorts (#16b)             ← smallest, ready to build, unrelated to live
+2. Live ingest (#16)         ← the WATCH foundation (Live tab, player, hls.js,
+                               chat, zaps) — a hard dependency of publishing
+3. Go-Live MVP (#16c P0–P1)  ← Tiers 1 & 2 (external embed + serverless HLS);
+                               CLIENT-SIDE ONLY, no Bridge / no VPS / no infra
+   ── ship it; validate that people actually want live ──
+4. (only if warranted) the Bridge app  ← Tier-3 sovereignty/power features;
+                               its own repo/toolchain/code-signing — a later track
+```
+
+The Go-Live MVP (steps 1–3) is the "as much static bitvid as possible" target: a
+real, working live experience where the creator brings their own provider
+(StreamYard→YouTube, or OBS→Livepeer/Mux) and bitvid does the Nostr-native part —
+publish, discover, watch, chat, zap, archive→VOD. Only after that proves out does
+a second app (the Bridge) earn the investment.
+
+---
+
 ## Phases
 
 - **Phase 0 — Flags + schema (small).** `FEATURE_LIVE_PUBLISH/BRIDGE/RESTREAM`;