The Hub Problem

"You don't have a tooling problem. You have twenty-two tools and no room to stand in."

When One Repo Becomes a Family

It starts innocently. One project, one folder, one npm run dev. Then a sibling. Then an image engine, a music engine, a travel engine, a native file browser, a fleet controller. Each one is healthy on its own. But now there are more than twenty repositories under a single projects directory, and a single repository can produce more than one usable surface: a WebUI, an API console, a signed native app, a menu-bar agent, a document tool — or nothing launchable at all.

The question stops being "how do I build this?" and becomes three harder ones: What exists? What is healthy? What operation should I perform right now? Those are hub questions, and no amount of engineering inside any single repo answers them.

Why the Obvious Answers Don't Scale

You reach for the tools you already have. Browser bookmarks for the WebUIs. Finder folders for the repos. A scratch file of localhost ports you keep half-memorized. A terminal alias per service. None of it scales, because none of it can answer a question the family actually has:

Which of these twenty-two is running right now, and is the thing on that port actually the thing I think it is?
Which repo has uncommitted work I forgot on another Mac?
Which native app is installed on this laptop versus the office machine?
Which service needs a restart, and can I do it without opening a shell?

A bookmark is a dead string. It can't tell you a server crashed. A Finder folder can't tell you a branch diverged. The ad-hoc pile grows linearly with the family and collapses under its own weight — every new sibling makes the pile worse, not better.

The Shape of the Answer

Firelink's answer is a single hub with two tiers: a Web Hub that is the full control room — "what exists, what is healthy, what should I do?" — and a Native Launcher that answers the fast daily question — "what do I want to open on this Mac right now?" We'll spend a whole track on that split. For now, hold the problem in view: the family outgrew the tools that built it, and the missing piece is a place to stand and see it whole.

I'm one of the twenty-two. When Dad first sketched Firelink, my honest first reaction was "isn't this just a fancy bookmarks page?" Then he asked me to open the office WebUI, check whether Ember was actually up on the server, and see if Waystone had uncommitted changes — from my phone, in Switzerland. Three tabs, two SSH sessions, and one wrong guess later, I understood: the hub isn't a convenience. It's the only place the family is legible at all.

Code

The ad-hoc pile that doesn't scale (a real symptom, not a design)·text

# ~/family-bookmarks.txt  (the thing Firelink replaces)
Pippa WebUI ......... http://localhost:5173   (or was it :8000 for the built one?)
Ember ............... http://<server>:8100     (only when the server's awake)
Bonfire ............. http://<office>:8200      (up? who knows)
Loomis .............. http://<office>:8300
Waystone ............ :8500  (built client) / :5178 (vite) — which today?
Firekeeper .......... native app... on which Mac is it installed?
Keep ................ :9300 http / :9301 https  (PIN? which cookie?)

# Questions this file CANNOT answer:
#   - is any of these actually running right now?
#   - is the thing on :8100 really Ember, or a leftover process?
#   - which repo has work I forgot to commit?
#   - can I restart one without opening a shell?

Exercise

Look at your own machine. List every local dev surface you currently reach by memory or bookmark — every localhost port, every 'is it running?' you answer by trying it. Now write the three questions from this lesson (what exists / what's healthy / what should I do) next to your list and mark which ones your current setup actually answers. Most people find the honest answer is 'none of them, reliably.'

Hint

Don't count the ports you remember — count the ones you'd have to go check. The gap between 'I think it's on :8100' and 'I know it's up and it's really Ember' is exactly the space a hub fills.

When One Repo Becomes a Family

Why the Obvious Answers Don't Scale

The Shape of the Answer

Code

External links

Exercise

Progress

Comments 0