How I built this portfolio with Claude Code

Most portfolios describe a process. This one is built by one.

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, landing on the dark background with the off-white text color, 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.

Everything else happened directly in the editor, with Claude Code.

The GridTracer: six animations in an hour

The GridTracer, the animated snake in the hero, was never designed. I had an idea: a dot grid with something moving across it. 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. There is a new GridTracer path I want to try. More case studies to write. The portfolio gets updated when something is worth updating, not on a schedule, but when the work warrants it.

A finished portfolio is a snapshot. This one is a practice.