Most portfolios describe a process. This one is built by one.
What you are reading is the fifth iteration of this site. Every version shipped to production, ran with PostHog analytics and session replays, and was reshaped by what those showed. Some iterations were large redesigns. Most were small fixes, one or two at a time. The version you see today may look different tomorrow.
What Figma was actually used for
Not much, honestly. Fonts, colors, some rough column structure. I did not design the portfolio in Figma and then build it. The design happened in the browser.
What I did spend time on in Figma: picking a typeface pair, settling an early color direction, and deciding that the layout should be full-width at the top and contained below. Those are fast decisions to make in Figma, and they would be slower to iterate in code. So Figma earned its place for that, maybe an hour, two at most. The color direction has shifted across iterations since then. The version you are reading now runs light, a Swiss-style layout on a paper background.
Everything else happened directly in the editor, with Claude Code.
The GridTracer: six animations in an hour
Earlier iterations had an animated element in the hero: a dot grid with a snake tracing across it. I called it the GridTracer. The current iteration does not have it, the hero is quieter now, but it is worth describing because the process is the point.
It was never designed. I had an idea, a dot grid with something moving across it, and that was the whole brief.
I started with that description and let Claude Code build a first version. It was rough. So I steered it, not with a spec, but by looking at what came back and saying "too fast," "the dots should be smaller," "I want the trail to fade slower." Six different animations in about an hour. One of them had a random walk, one had a fixed snake path, one had multiple traces running simultaneously. I could see each in the browser immediately and react to it. No Figma prototype would have gotten me there. I would have spent the same hour building one spaghetti prototype that still would not have told me how it actually felt to watch.
The winner was the snake. I kept steering until the path algorithm, timing, and fade-out matched what I was looking for. That whole process would have been impossible at that speed without being able to ship and see in seconds.
Exploring options in parallel with worktrees
One of the things I started using heavily was git worktrees. When I was not sure which design direction to take, a different hero layout, a new cards approach, a different type scale, I would create a worktree for each, explore them independently, then compare the results side by side.
This changed how I think about design exploration in code. Instead of committing to a direction early, I could have three running simultaneously. Sometimes one was clearly better. Sometimes I would cherry-pick components from two branches and merge the best of each. The cost of exploration dropped significantly once I stopped treating each direction as a throwaway experiment and started treating it as a real, reviewable artifact.
Figma has artboards for this. Code has worktrees. They are solving the same problem.
Where Claude Code needs steering
The pattern that works: get a first draft, look at it in the browser, identify specifically what is off, give targeted feedback. The mistake is describing the ideal outcome upfront and expecting a match. React to what you get instead, because what you get is usually almost right, and knowing what "almost right" looks like is most of the job.
Where it consistently needs correction: design system tokens (it will use raw hex values unless you tell it to use the variables), abstraction creep (it will extract utilities that do not need to exist), and visual balance (it has no eye for optical alignment or spacing that feels right at actual size). Those are judgment calls, and judgment is what you are bringing to the process.
You are always the reviewer. That is the right division of labor.
What this changed about how I work
Speed changes what you are willing to try. When a new component takes five minutes instead of an hour, you try more of them. When you can compare two layouts in parallel and merge the best parts, you do not have to bet on one direction early. The cost of being wrong dropped, so the cost of exploring went down with it.
The portfolio improved visibly sprint by sprint, one or two shipped features at a time, not a roadmap item, just something better than what was there before. That visible iteration turned out to be more motivating than any "coming soon" section would have been.
Still evolving
That is the point. Same principle I would recommend for client work: ship early, improve continuously. This is the fifth iteration, and it will not be the last. The portfolio gets updated when something is worth updating, not on a schedule, but when the work warrants it.
The changes come from data. PostHog analytics and session replays show me what people actually do here: which projects they open, how far they read, where they lose interest. The site evolves around that. The version you are looking at today is a snapshot of what I understand right now. As I learn more about how people move through it, it changes. It may not be the same tomorrow.
A finished portfolio is a snapshot. This one is a practice.
