Every developer portfolio I’ve built has died the same way: I ship it, it looks good for a month, and then it quietly falls behind every project it’s supposed to describe. The gap between “what I’m actually working on” and “what the portfolio says I’m working on” only grows, because updating it is a separate chore competing with the work itself.

Hub is my attempt to stop treating that as separate work.

The idea

Instead of a static page I remember to edit, Hub is a flat catalog of every product I run or ship — software or not — populated from real development activity. A local LLM reads each tracked repo’s own git history and drafts journey entries and weekly rollups; a stateless digest API turns that into structured content; and everything lands as a reviewable GitHub PR before it publishes anywhere. Nothing goes live without me merging it, but nothing requires me to sit down and write it from scratch either.

Why self-hosted, end to end

I didn’t want a CMS in the loop, and I didn’t want a hosted AI API bill that scales with how much I ship. Hub runs on a Mac mini I already own — scheduling, local inference, the works — with the site itself a static Astro build. The tradeoff is setup time up front; the payoff is that the whole system costs nothing to keep running and nothing leaks to a third party.

What “living” actually means here

Concretely, three things happen automatically that used to be manual:

  • Per-product journey entries get generated directly from git activity, so a week of real commits becomes a real update without me writing one.
  • Weekly and monthly rollups synthesize progress across everything I’m tracking, so the top-level feed reads like a narrative instead of a changelog dump.
  • Blog articles get proposed, independently of the rollup, reviewed and merged like any other change — this article is one of them.

None of it skips review. Every AI-drafted piece of content is exactly that — a draft — until a PR is read and merged. The automation’s job is to get a reasonable first draft in front of me, not to publish unsupervised.

Where it stands

Right now Hub is still mid-build: the site skeleton, product pages, and journey feed are coming together component by component, each one its own reviewed PR against a written spec before it merges. The sync pipeline that will eventually keep web_app/src/content/ current from hub/’s canonical fanned-out source doesn’t exist yet, so a lot of what’s on the site today — this article included — is placeholder data standing in for what the real pipeline will produce.

That’s fine. The point isn’t to have a finished product on day one; it’s to have a system where “the site describes what I’m actually doing” stops being something I have to remember to do by hand.