The Project Hub: Every Link a Project Runs On, in One Place

Think about the last project you shipped. Not the code or the deck — the URLs. There was a cloud console. Probably three: one for hosting, one for the database, one for DNS. A status page. An analytics dashboard. Two or three API docs you had open constantly. A repo. A design file. A shared drive. A client portal. An invoice. Somewhere, a Slack thread with the one credential nobody wrote down properly.

That is twenty-odd URLs across half a dozen services, and none of them live together. They live in your history, in a Slack search, in an email from four months ago, and in the muscle memory of typing three characters into the address bar and hoping autocomplete remembers. It works, right up until you come back to the project after eight weeks on something else.

The problem is not the number of links

It is that they are organized by what they are — bookmarks here, docs there, credentials in a password manager, client files in a drive — when the only question you ever ask is what does this project need.

Nobody has ever thought "I would like to look at a cloud console". They think "the staging deploy failed", and the answer to that involves four specific URLs belonging to one specific project. A structure that makes you visit four different tools to assemble that set is charging you a tax on every context switch.

One branch per project, one shape inside it

The structure that works is boring and repeats itself. A project gets a branch, and every project branch has the same handful of children:

Acme rebuild                 ← the project
  Infrastructure
    AWS                        ← console, the specific region
    Cloudflare                 ← DNS, cache rules
    Railway                    ← the staging deploy
    Firebase                   ← auth, the one used for push
  Docs & APIs
    Payment provider
    Internal API reference
  Tools
    Analytics
    Error tracking
    Uptime / status pages
  People & admin
    Client portal
    Shared drive
    Invoices
  Reference
    Prior art we said we liked
    The thread where we decided

Five children, the same five every time. The value is in the repetition: after the second project you stop deciding where things go, and after the fifth you can find the equivalent link in any project without thinking, because it is in the same place it was in the last one.

Note the depth. "Infrastructure → AWS" is not decoration — one project touching four providers is normal, and each provider is several links (the console, the specific S3 bucket, the billing page). Two levels of nesting is not enough for real work, which is why a tool that caps you there pushes you into folder names like "Infra - AWS - Prod" and, from there, into giving up. Inspistor uses an adjacency-list schema with no depth limit for exactly this reason.

It is not a developer thing

The same shape holds for any work that runs on more than one system, which is now most work:

The through-line is that projects are the unit of work and services are not. Whoever you are, the thing you switch between is a project, so that is what the top level of the structure should be.

Save the reason, not just the URL

A console URL is meaningless six weeks later. https://console.aws.amazon.com/s3/buckets/acme-prod-assets tells you it is a bucket. It does not tell you it is the one the CDN reads from and the one you must not touch during business hours.

One sentence per link is the entire difference between a hub and a pile:

• Cloudflare — "cache rules live here; purge after any CSS deploy or the client will call."
• Railway — "staging only. Production is on the other account, the one under the client's email."
• That analytics dashboard — "the numbers the client actually reads in the Monday call."
• The listing portal — "log in as the office account, not yours, or the lead does not get attributed."

These take five seconds to say and are the reason handing a project over takes ten minutes instead of a day. Speaking them beats typing them by a factor of five, which is the whole argument for voice notes — not that dictation is impressive, but that a fifteen-second task gets skipped and a three-second one does not.

Build the hub as you work, not in one sitting

A dedicated afternoon of link-gathering produces a beautiful hub for the project you are least likely to need it for. Build it from the actual work instead:

1. 1

   Make the branch when the project starts

   Five empty sub-branches, thirty seconds. The empty structure is what makes the next step automatic — the decision has already been made.

2. 2

   Save on the second visit, not the first

   The first time you open a console you might never open it again. The second time is proof it belongs to the project. This single rule keeps the hub at the twenty links that matter rather than the two hundred you touched.

3. 3

   Say the reason while the tab is still open

   You will never have more context about a link than in the five seconds after using it. Capture it there or not at all.

4. 4

   Clean the URL as you save

   Console URLs carry session and region junk; marketing links carry a tail of tracking parameters. Both break deduplication and both make a link unreadable at a glance. A URL cleaner handles a batch, but the habit is what matters.

5. 5

   Archive the branch, do not delete it

   When a project ends, move the whole branch under "Archive". Six months later a client asks a question about it, and you answer in thirty seconds instead of reconstructing an entire environment from memory.

Why bookmarks fail at this and what fixes it

Browser bookmarks have the right idea and three specific defects, all of which are fixable:

• No room for the reason. A bookmark has a title and a URL. Everything you knew is discarded. Fix: a tool with a note per item, and a search that reads the notes.
• They are per-browser. Your work Chrome, your personal Chrome and your phone each have a different library. Fix: a library behind an account, so the extension and the dashboard show the same thing.
• Nothing is ever removed. Bookmarks accumulate for a decade with no maintenance. Fix: an archive branch per finished project, and one pass with a duplicate finder when the list stops feeling trustworthy.

None of this requires a specific product. It requires that saving a link cost less than losing it, which is mostly a question of how many decisions and how many app switches the save costs you.

What it feels like when it works

You come back to a project after two months. You open one branch. The consoles are there, in the order you use them, each with a line explaining what it is for. The client portal is there with the note about which account to log in as. The reference thread where a decision was made is there, so the argument does not restart.

The gain is not the two minutes of searching. It is that you can pick a project back up without first rebuilding the mental model of where everything is — and that is the same reason this works whether the links are cloud consoles or listings.