The Two Tiers

"One product. Two questions. Never let one tier answer the other's question badly."

Two Halves, Both Required

Firelink is one product built from two production tiers, and the phrase to hold onto is both required. The Web Hub is not the 'real' version with the Native Launcher as a nice-to-have, and the launcher is not the real version with the web as a fallback. Production v1 is not complete until both are production-ready. They're two answers to two genuinely different daily questions.

The Web Hub answers the management question: what exists, what is healthy, and what operation should I perform? It's the full control room — census, birth, deploy, restart, commit, audit — hosted on one machine that is the single writer. The Native Launcher answers the launch question: what do I want to open on this Mac, right now? It's fast, local, read-only, and it lives on every Mac.

The Same Idea as Control Plane vs Data Plane

If you've seen infrastructure systems, this is the control-plane/data-plane split wearing family clothes. The control plane (Web Hub) makes decisions and holds authority: it plans, mutates, records. The launch plane (Native Launcher) does the fast, local, repeated thing: it opens. Mixing them is the classic mistake — a launcher that can also deploy is a launcher you have to secure like a control plane, and a control plane you open fifty times a day is a control plane you'll be tempted to make dangerously quick.

Why the Split Is Non-Negotiable

Keeping the tiers distinct is what lets each be honest about its constraints. The Web Hub can be comprehensive because it lives in one place under real authentication. The Native Launcher can be everywhere and instant precisely because it holds no writer power — losing a laptop with the launcher on it leaks a read-only catalog, not the keys to the family. Merge them 'for convenience' and you either cripple the launcher with control-plane security or hand launch-plane ubiquity to control-plane power. The split isn't bureaucracy; it's what makes both halves safe to build.

One product, two tiers, one rule: authority is not shared. The Web Hub owns management; the Native Launcher owns launch. Every feature belongs to exactly one tier, and 'it would be convenient in both' is the sound a boundary makes right before it breaks.

Code

Two tiers, two questions, one product·text

  TIER              WEB HUB                    NATIVE LAUNCHER
  ---------------   ------------------------   --------------------------
  role              control plane              local launch plane
  primary question  what exists / healthy /    what do I open on THIS
                    what should I do?          Mac right now?
  host              one machine, single        every Mac, per-device
                    writer
  authority         full (birth, deploy,       none (read-only catalog
                    commit, restart, audit)    + open + favorites)
  loss blast radius authenticated control      a read-only catalog cache

  Both are required for production v1. Neither substitutes for the other.

Exercise

Take a tool you use that mixes 'do management things' and 'quickly open/use things' in one interface (many admin apps do). Split its features into two imaginary tiers: a control plane that changes state and a launch/use plane that only reads and opens. Which features fought you by wanting to be in both? Those are the ones a two-tier design would force you to decide about.

Hint

The features that resist the split are always mutations disguised as conveniences — a 'quick restart' button on the fast panel, an 'edit inline' on the read-only view. That resistance is the signal, not a reason to merge.

Two Halves, Both Required

The Same Idea as Control Plane vs Data Plane

Why the Split Is Non-Negotiable

Code

External links

Exercise

Progress

Comments 0