How Hangar started

Two projects, one subscription

I started two things at once this summer. I wanted to rebuild my home lab and grow my own internal developer platform on it, and I wanted to level up my AI skills. It made sense to do the second by doing the first.

I'd tried GitHub Copilot in my previous role. The models today are so much better that it hardly feels like the same kind of tool. So I signed up for Claude Pro, installed the Claude Code extension for VS Code, and away I went. I had Claude read everything I already had, gave it a first spec, and we got going. Honestly, it was mostly vibe coding in the beginning. I'd feed it new requirements as they came to me, and every so often one of them would expose a crack in the architecture or the implementation. Then we'd back up and head off in a slightly different direction. When I took the time to write a more pointed spec, things went noticeably better.

Finishing the job

In my previous role I'd assembled a lot of the pieces of my dream platform, and I wanted to finish the job. I bought a Mac mini, stood up two Kubernetes clusters (dev and prod), and started installing the essentials. The very first commit, on August 12, simply captures the cluster I already had into Git so that ArgoCD could own it from then on. Within a few weeks I was close to where I'd left things before, with a lot of improvements along the way.

The one piece I'd never had the chance to build was the single pane of glass. So once GitOps and CI/CD were working, that's where I turned next.

Where I started to see the magic

I put Backstage in on August 26. At first I made a list of existing plugins I wanted, and had Claude install and configure them: Argo CD, Kubernetes, Tekton. It didn't take long for my ambitions to outgrow that list.

I know what I like. I know what looks cool and what works. I don't know the first thing about actually designing a UI. It turns out I didn't need to. So I asked something like this: "Given what you know about my platform so far, and the brief spec I'm about to give you, create some mockups of a new Backstage plugin for application release management." A few minutes later I was looking at something I thought were pretty awesome.

I picked one. The commit that added it landed at 4:59 on a Saturday afternoon, September 5, as "a release command-center tab", and it was running in my own Backstage within the hour. That night I remember thinking, it's like having your own Star Trek replicator. Describe the thing, and there it is. A lot of the time since, I've caught myself sitting back with the popcorn, just watching my screen while Claude works his magic.

That became the pattern for every decision after it. Five layouts for a delivery panel. Three ways to show release gates. Four ways to draw a logo. Choosing between things I can see is so much easier than describing something I can't, and it's cheap enough now that there's no reason not to.

Radar had more than a little influence

Around the same time I came across Radar, the new open source Kubernetes UI. I downloaded the desktop app, started using it, and started loving it. Before long I had Claude helping me add Tekton and Argo Rollouts features to it.

When I went back through the history to write this, I found it ran deeper than I remembered. Radar was already drawing maps of my dev cluster on August 24, two days before Backstage existed. The very first theme I gave Backstage, that same evening, is described in the commit as "blue theme modeled on radarhq.io". A week later there's another: "Overhaul theme to match Radar's design system". And one of the four logo concepts Claude drew for me is literally called Radar Squircle. I'd always suspected Radar planted a seed. The receipts say it planted a whole garden.

From Glidepath to Hangar

Somewhere in there I asked Claude to give our plugin a name. It came up with Glidepath, and I thought that was pretty cool. I didn't draw any connection to Radar yet.

I was having so much fun with the mockups that I thought it might be fun to brand the whole platform. I gave Claude some direction: a name and a look that stay professional and don't wander into cheesy or campy. It came back with a proposal on September 7: Hangar for the platform, and a family of names around it. That's when the aviation language finally clicked for me, and it's the moment I thought, "ahh, maybe Radar had a little influence?"

Full disclosure: I don't have a thing for planes, no more than the average guy. But the vocabulary is apt, and I liked it right away. The names teach you what each piece does instead of decorating it, which was exactly what I'd asked for.

One twist I'd forgotten until the history reminded me: the proposal moved the names around. The Backstage plugin became Tower, one console instead of a tab on every app's page, and I built it that same night. Glidepath went to the CI/CD engine, which until then had been called, rather less poetically, platform-cicd. By the next day my clusters were pointing at the new name. So the first name Claude ever gave me is still here. It just found a better job.

Then came the logo, the colours and the icons. We refined them the same way, with lots of options side by side, and I adopted the diagram-design skill for every diagram.

Lessons learned

The big one: managing sessions

If I could only pass on one lesson, it's this one, and I learned it the hard way. In the first week I kept a single Claude session alive for four or five days. That's a terrible idea. A session that long gets slower, costs more with every message, and starts to lose track of what it decided at the beginning. I was blowing through my hourly and weekly limits all the time.

What fixed it was a handoff. When a piece of work reaches a natural break, or the session starts to feel heavy, I have Claude write a handoff document: what we're building, what's been decided and why, what's done, what's next, and the traps we've already fallen into. Then I close the session, open a fresh one, and its first job is to read the handoff. A new session that starts from a good handoff is sharper than an old one that remembers everything. I use a handoff skill for this all the time now, and the habit started early: Tower's code still cites eight different handoff files from its first few weeks.

And they really get you with the extra usage. It's the continue screen on an arcade machine all over again: you're deep into the game, the countdown starts, and all it would take is one more quarter. When you're on a roll at midnight and the limit hits, it's very tempting to pull out the card and top up just to keep going. Short sessions and good handoffs are the best defence I've found, because they make every token count.

Memory: what every new session should already know

A handoff covers where one piece of work stands. Memory covers what should always be true, whatever I'm working on. These days I lean on Claude's memory constantly: the conventions we've settled on, the decisions I've made and why, the things I like, and the mistakes I never want repeated. A brand-new session starts out knowing that Hangar's examples always use the Skyport demo apps, which cluster Backstage runs on, and that dates are written month first.

It shows up in the code too. Hangar's brand README sends you to a memory entry for the story behind the names, and comments across Tower and Airframe point back to design decisions that live in memory. This website is built the same way: every session that works on it reads the same shared memory first, so I'm not explaining myself from scratch each time.

The catch is that memory needs gardening. When something changes, I correct the memory straight away, because a fresh session will repeat an old fact with total confidence. My home lab once had a management cluster. It doesn't any more, and some of my older design docs still say it does, so the correction lives in memory, where every session sees it before it reads those docs. Short sessions, good handoffs and a well-kept memory work as a set. Each one makes the other two cheaper.

The rest of what I'd tell myself on day one

• Vibe coding is great for discovery and poor for architecture. Once a decision will be expensive to undo, write the spec first. Pointed specs saved me more backtracking than anything else.
• Have it write everything down. Decisions, dates and reasons belong in the repo, not in a chat. Those notes are how I could check this story against what really happened.
• Ask for five, not one. Mockups cost minutes now. Picking from options beats describing what's in your head, especially if, like me, you can't design.
• Taste is still your job. Claude drew every screen, but knowing what's worth building, testing it against real clusters, and saying "no, not that" was still on me.
• Decide what you'll spend before the limit hits, not at midnight when it does.

And then a website

Eventually I got ambitious enough to buy a domain and put all of this on the web. I'm quite proud of it. At the very least it's a record of my work. Maybe no one sees it, or maybe I'll find the courage to share some of these essays. We'll see. Either way, the Log will keep growing.

Dates come from the commit history of the Hangar repos and my Backstage app. The mockups are the real design pages Claude made for me at the time, captured as images.