Case Study
I rebuilt my portfolio without a CMS and without writing the code myself. What I really built was a way of working with Claude that survives its forgetting and leaves the taste calls to me. It's now a playbook that runs my other projects too.
My workflow wasn’t working. I’d ask Claude or ChatGPT how to do something, then go back into Webflow and do it myself, by hand. Webflow also capped what I could build. Rebuilding the site in code let me step back into a director role and leave the execution to Claude.
Directing Claude across weeks of work meant solving a problem before writing any code: Claude forgets. Long sessions get summarized to fit, some end mid-task, and a new session remembers nothing from the last one. So alongside the site, I built a playbook with Claude for working on a project that outlasts any one conversation.
The core idea comes from Jake Van Clief’s Interpretable Context Methodology: Folder Structure as Agent Architecture: the folder structure does the work, so the file system is the memory. Anything a future session needs to know goes into a file, because the chat won’t be there tomorrow. Every project gets two kinds of documents that change at different speeds: stable docs that say what the project is and what done looks like, and living state files that say exactly where the last session stopped and what happens next. Every session starts by reading them in a fixed order. Decisions go into a log with the date and the reason, so a settled question stays settled instead of being argued again next week.
Keeping context in files also means I install fewer Claude skills, the packaged instructions Claude loads for a particular task. The folders show Claude where to find what it needs, and because those instructions live in the project itself, I can change them mid-task without switching away from what I’m working on.
Before any code, I listed what the rebuild could never change: the astronaut, the CMYK color relationship, and the cosmic world theme. I also kept content out of the rebuild: the case studies moved over word for word, and rewriting them waited for a later phase. Anything touching that list comes to me. Everything else, Claude does without asking, and I review the work at milestones.
I set one core rule for how work gets built: the main Claude session never writes code. It writes the done-conditions for a piece of work and hands the building to a subagent, which checks the result in a real browser before it reports back. The main session judges the report. A session that fills with code and build logs starts losing its grip on the details I care about most, so keeping the code out keeps its memory for decisions.
The playbook is a work in progress. The playbook tells Claude to propose a new rule when something breaks down. Claude proposes, and I decide whether it stays.
After catching Claude claiming two features had shipped when I knew they hadn’t, I asked Claude to trace the source of the confusion. The docs were several logs, each claiming to describe the current state, and nothing tied any of them to what was actually deployed. Now Claude runs a script before it answers any status question, checking the docs against the code, the deployment and the live page.
I’d rather have fewer rules, and the script shows why: one check against what’s deployed covers every place the docs could drift.
A rule can also be wrong. I kept pushing for the planet’s horizon to show when the homepage loads on mobile, and Claude kept claiming it couldn’t be done. When I pressed, it turned out to be a rule I’d never made. Claude had inferred it from a reference screenshot, written it into the build brief as a hard constraint, and its verifying subagents had enforced it through round after round. I repealed it and added a crosscheck: no hard constraint goes into a brief unless it traces to my own words or a locked decision. Verifiers enforce whatever they’re given, so I review the rules as closely as the work.
The first build of the hero read to me like a night sky seen from earth, when my Webflow site had felt like space at the edge of the atmosphere, so I picked the one of Claude’s three mockups that brought that back.
The living polaroid in my About section is built from four layers I supplied: the background, the rocks, me mid-jump, and the frame. It’s supposed to look like a photo you can see inside of, not a fishbowl of objects floating around at random. Claude’s first versions let the layers drift on their own, and the fix was the plainest direction I could give: just the polaroid as a whole floats.
I built the playbook for this portfolio, then adapted it for everything after. It runs Fridgeface, the five-shape alphabet elsewhere in this portfolio, along with my other personal projects and my work projects. If you want to hear more about how it works, get in touch.
The cover, both illustrations and the polaroid diagram were generated with Nano Banana Pro in Figma Weave; the diagram is built from my original photo layers.