Back to Journal

4 July 2026

The Rabbit Holes: What Building an App Actually Looks Like

building-in-publicsolo-founderailessons

Most "building in public" posts show you the highlight reel. The feature that shipped. The clean before-and-after. The graph going up and to the right.

This isn't that post.

Because the honest truth of building something — especially as a non-developer leaning on AI to do the heavy lifting — is that a real chunk of the time isn't spent building at all. It's spent stuck. Down a rabbit hole. Staring at something that should work, doesn't, and gives you no clue why. And the rabbit holes are rarely the big scary technical problems you'd expect. They're the small, stupid, infuriating things.

Here are some of the ones that actually ate my time. I'm sharing them because if you're thinking of building something yourself, I want you to know the mess is normal — and none of these were the thing I thought would be hard.

The day I lost to a font

Early on, I switched the app over to a proper styling system so it would match my brand — the magenta and cyan, the specific off-white for body text. Simple enough in theory. In practice it broke things for a good while.

The styling pipeline needed several config files wired together in exactly the right way, and when one small piece was off, nothing rendered — not an error, just... the change silently not appearing. I'd tweak something, reload, see no difference, and have no idea whether I'd fixed it, broken it further, or changed the wrong file entirely.

Then, once it was working, I discovered the AI had quietly filled in a bunch of my status colours with generic default values — a stock red, a stock green — that looked visibly wrong next to my actual palette. Everything "worked," but it was subtly off-brand in a way I only caught because I went through the colour values one by one.

The lesson: "it works" and "it's right" are two different finish lines. The tools are brilliant at getting you to the first one. The second one is still on you to check.

The blog you're reading nearly didn't publish

Getting this very journal live was its own saga. The site would build fine locally, then refuse to deploy — with an error that had nothing to do with the actual problem. It complained about a "user not found," which sounds like a login issue. It wasn't. The real cause: the email address attached to my code commits didn't match a verified email on my account, and the hosting platform silently refused to deploy anything from an "unrecognised" author.

Nothing in the error pointed at that. I only got there by ruling out everything else first. One config line later, it deployed instantly.

And then there was the newsletter signup box, which took an embarrassing amount of trial and error to sit on the page correctly — the kind of thing where you nudge it, reload, nudge it again, and slowly converge on "good enough" rather than ever really solving it cleanly. Some rabbit holes you don't defeat. You just negotiate a truce.

Losing your train of thought — literally

Here's one specific to building with an AI partner that I didn't see coming: memory doesn't carry perfectly between sessions.

When you work with an AI over a long project, each conversation has a limit. Hit it, and you start a new one — and some of the shared context, the momentum, the "we were right in the middle of this," gets thinner in the handover. It's a bit like handing a project to a very capable new colleague who's read the notes but wasn't in the room for the last three hours. Mostly fine. Occasionally you have to re-explain a decision you thought was settled, or re-establish why something is the way it is.

I learned to compensate by keeping obsessive written notes — a running document of every decision and why — so the context lives somewhere permanent, not just in a conversation that might reset. That documentation habit turned out to be one of the most valuable things I do. Not because it's satisfying (it isn't), but because it's the thing that lets me pick up cleanly after a break, or after a reset, without losing the thread.

The bugs that weren't bugs

Two of my favourite time-sinks turned out to be problems that didn't exist.

Once, a feature looked broken — it was showing one result when I was sure it should show two. I was ready to tear the code apart. The actual cause: the way I'd checked the data behind the scenes was counting everyone's records added together, while the app was correctly showing just mine. The app was right the whole time. My test was wrong. I'd nearly "fixed" working code.

Another time, an artist's history stubbornly showed a wrong date. The logic for picking the most recent event was grabbing the first one it found instead of the newest — a subtle difference that's invisible until it isn't.

The lesson from both: when something looks broken, question your assumptions before you question the code. Half the time the rabbit hole is in your own head, not the machine.

The environment gremlins

And then there's the ambient tax of a real setup. My machine runs a security layer that intercepts network traffic, which means half the standard commands fail unless I prefix them with a specific incantation I now type on autopilot. It's not hard once you know. But the first time something fails for that reason, you have no idea it's the environment and not the thing you're building — so you go hunting for a bug that isn't there.

Multiply that by every tool having its own quirks, and a real portion of "building" is just knowing which gremlin lives where.

Why I'm telling you this

None of these were the hard part I expected. I expected the features to be hard — the database, the search, the personalisation. Those mostly went fine. What actually cost me time was fonts, a commit email, a signup box, a reset conversation, and a couple of bugs that were really just me misreading my own data.

That's the real texture of building something. And here's the encouraging bit: none of these required me to be a better programmer. They required patience, good notes, a willingness to question my own assumptions, and the stubbornness to keep ruling things out until the real cause showed itself. Those are things anyone can do.

The rabbit holes aren't a sign you're doing it wrong. They are the doing.

More soon — probably after the next rabbit hole.

Follow the build

Occasional updates as we ship ItsOnLive — progress, not spam.