Skip to content
4 min read

How I built this portfolio with Claude Code

An honest account of building a Next.js portfolio with AI tooling — what Figma was actually used for, how the GridTracer got made, and what working with worktrees taught me about design exploration.

Claude CodeDesign ProcessNext.jsAI Tooling

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 didn't design the portfolio in Figma and then build it — that's not how it went. 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'd 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'd have spent the same hour building one spaghetti prototype that still wouldn't 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 wasn't sure which design direction to take — a different hero layout, a new cards approach, a different type scale — I'd spin up 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'd 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're solving the same problem.

Where Claude Code needs steering

It's not a vending machine. You don't describe what you want and accept the result.

The pattern that works: get a first draft, look at it in the browser, identify specifically what's off, give targeted feedback. The mistake is describing the ideal outcome upfront and expecting a match. The better move is to react to what you get — 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'll use raw hex values unless you tell it to use the variables), abstraction creep (it will extract utilities that don't need to exist), and visual balance (it has no eye for optical alignment or spacing that feels right at actual size). Those aren't bugs — they're judgment calls, and judgment is what you're bringing to the process.

You're always the reviewer. That's not a limitation of the tool; it's the right division of labor.

What this changed about how I work

Speed changes what you're 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 don't 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.

It's not finished

That's the point. Same principle I'd recommend for client work: ship early, improve continuously. There's 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.