How I Directed the RoleNavigator Redesign

The “AI built a website” framing misses the part worth understanding.

I spent parts of three days redesigning rolenavigator.com with Claude Code. The result: 87 commits, 21 custom watercolour illustrations, a 32-second tour video, real app screenshots, and a homepage that doesn’t require careful reading to figure out what the product does. The commit count isn’t the story I want to tell.

The story is about how the work got divided.

What I owned and what Claude owned

Claude owned process. It ran the design interview one question at a time, generated options with a recommendation, built the implementation plan, ran verifier agents to check the code matched the spec, and logged every judgment call with its reasoning and a cost estimate if it turned out wrong.

I owned taste, copy, facts, and any decision that couldn’t be undone.

Every illustration, every line of copy, every privacy claim, every merge, every deploy was mine. Claude asked for a decision at exactly those points. It kept moving the rest of the time.

This sounds cleaner than it was. The friction is where the honest picture lives.

What Claude already knew

Before I typed the kickoff prompt, Claude had context I’d built up over months of working in this repo.

The repo has a CLAUDE.md file encoding rules from actual failures, not blog-post best practices. One rule: exactly one builder touches the live site at a time. That rule exists because an article publish once silently reverted site features while a site deploy reverted the blog on the same day. Two overwrites, both silent. The rule came from that day.

Other rules: every build must produce byte-identical output from the same inputs, and a script runs on every build to prove it. If ContentEngine is unreachable at publish time, the publish must fail before uploading, because an earlier version finished a partial upload and wiped every article off the live blog.

There’s also a rule about my personal site: Claude never touches anything on justinhammon.com. It shares a build host with RoleNavigator, and one careless script that doesn’t respect the boundary could wreck two sites at once without either making noise about it. The rule is one line in the file. It holds because the file is there.

Claude also keeps persistent project memory. Notes that carry across sessions: how the ContentEngine integration works, how the Cloudflare setup is structured, scope-your-commits-never-run-git-add-A, a few others. That context exists because I caught problems and wrote them down. The redesign moved fast partly because we didn’t spend the first hours rebuilding what was already in place.

How the design phase ran

My kickoff message was three sentences. I wanted the site more human-centric, more illustrative, real screenshots, and a 30-second video tour. I asked Claude to run its structured design process and interview me.

What followed was about 45 rounds of questions over roughly 16 hours of wall-clock time, from opening direction all the way through final copy choices. The questions covered character design and cast, hero layout, screenshot approach, video pacing and audio, and typography. Each came with options and a recommendation. Most of my answers were one letter.

The visual side ran through a browser companion. Claude served a page on my home network showing mockups, option grids, and screenshots as they were generated. I’d look from my remote machine, type a letter in the terminal, and we’d move.

One exchange that became a standing rule: I told Claude that script-font accent text looked like “AI slop” and wanted alternatives. It showed me options. I picked a hand-drawn ink underline for the hero headline and monospace field-note captions. Claude saved that as a persistent memory, so future sessions don’t re-litigate it.

The friction

This is the part most build-in-public posts skip. The friction is where the work of this kind of collaboration actually shows up.

Remote access. I work from a different machine than the one running Claude. Early in the session, a safety check blocked the companion from serving on my home network, which was how I’d been accessing it since April. I said so, ran the start command myself, and it worked from there.

Being asked to do mechanical steps. Partway through the screenshot work, Claude started asking me to take actions on my own systems that it had managed before. My response: Let’s just say it was… direct. Claude stopped asking me to handle mechanical steps on systems it already had access to, saved a memory about it, and we moved on.

Wrong environment. Claude started capturing screenshots from the wrong account. My correction: “I don’t think the demo account lives on the live account. It lives in dev.” Claude switched, updated the spec to make dev the canonical screenshot source.

The hero. After several rounds, Claude showed me a homepage hero that was bad in ways I couldn’t fix by describing them precisely. The good news: “That hero home page looks like trash.” Seemed to work. It got rebuilt. Claude saved a memory: look at every capture with a designer’s eye before showing it. Passing tests is not the bar.

The illustrations. At one point during the character art rounds: “Stop being lazy and focus!” More variants per round after that.

None of these are disasters. They’re friction, which is different. The work of getting an AI tool to behave the way you actually need it to on your real production systems is iterative, not automatic. You call out problems. You encode the fix. It holds in future sessions because it’s in memory or CLAUDE.md.

What I’m taking from this

I directed this. I didn’t just review it.

That distinction matters more than it sounds. When I caught that Elena’s notebook was upside down, or that Priya’s eyes weren’t on the papers, or that two coffee mugs on my desk made no sense for someone in a job search, those weren’t edge cases. That was the work. Taste doesn’t transfer through a prompt. You can’t write your way out of having to look at something and know whether it’s right.

What Claude handled well: process, verification, continuity across sessions, and written reasoning I could audit. The spec-conformance reviewer ran after every task and caught real problems, including a homepage FAQ that contradicted the app’s own privacy policy on data sharing. That one mattered. I wouldn’t have caught it in a manual pass.

Three days. 87 commits. 300-plus tests. Real screenshots from a dev demo account. A tour video. A homepage that didn’t exist five days ago.

Fastest I’ve moved on something this size. Most involved I had to stay throughout. Those two things aren’t in tension. That’s the deal.

If you’re working the same way, the CLAUDE.md file is where the lessons go. Not documentation for some future engineer. Rules from the specific day something broke, with enough context about what happened that future-you doesn’t have to reconstruct the reasoning from scratch. That’s what makes it fast next time.