I Built My First Site. The Code Was the Easy Part.

I shipped my first personal website using Claude Code with no prior React experience. The build was fast, but what mattered was the prep work and design judgment that the AI couldn't do for me.

Published: 2026-04-28

I am not a front-end engineer. Three days ago I had not written a line of React, did not know what Vite was, and could not have told you the difference between a <div> and a <section>. What I knew about UI came from prototyping with Python in Streamlit. What I knew about reading frontend code came from writing web scrapers. I had built years of enterprise products as a PM but zero of my own things shipped to a public URL.

This week I shipped yihuisong.com.

The actual code was written by Claude. I used Claude in the chat to think through positioning, design, and structure, then handed the implementation off to Claude Code. The site went from empty repo to deployed in three days. Shipping is faster than ever.

The interesting part is what Claude needed from me before it could be useful. The site became unique because of the work I did before opening Claude Code, and the decisions I had to make while it was building. If I had skipped those efforts, I would have ended up with a perfectly functional site that looked like every other AI-built personal site from this year.

That's the part of the AI-build wave I haven't seen written about. Everyone is talking about how fast the building got. I find it more worth discussing what the human still has to bring to the table, and what happens to your output when you can't bring enough. Here is what I learned.

Before The Code: Two Pieces Of Prep That Mattered More Than I Expected

1. Working through branding and positioning with Claude. I spent an evening with Claude in the chat to explore personal branding and site positioning. I didn't open with "build me a personal site for a product manager." That kind of prompt produces a generic site. Instead, it was a longer conversation about who I am, who I want the site to reach, and what I want them to think about me after twenty seconds. The output was a SPEC.md. It was a brief that answered what this site actually was, which clarified visitor personas, exact hero copy, design tokens, an "out of scope" list. It had nothing to do with code yet. It became the foundation everything else was built against.

2. Tailoring an existing template's prompt structure.

I went to motionsites.ai, a site that generates aesthetic React templates from prompts and exposes some of those prompts publicly. You can copy them, paste them into any coding agent, and reproduce the template.

Here's what's worth noting about motionsites.ai: the prompt structure itself is the leverage. Each prompt serves as a scaffold for visual direction, which covers aesthetic direction, palette, typography, layout pattern, motion, and interactions. I needed that scaffold because I didn't have the language to write a prompt like that from scratch. Terms like "layered gradient overlays," "glass nav pill," "staggered fade-ins" had passed me by in conversations and articles, but I couldn't have produced them on demand.

I picked a template whose visual vocabulary fit the SPEC: Cormorant Garamond display serif paired with Inter, a glass nav pill, layered gradient overlays, a video background with a custom cross-fade loop, slow staggered fade-ins. I also tuned the prompt with other website design examples as visual references. The output turned out to be beyond my expectation.

For someone who isn't fluent in frontend vocabulary, finding a well-structured prompt to adapt is faster than learning the vocabulary first.

Both pieces of prep required something Claude couldn't supply on its own:

What Claude Does Well

Claude Code was excellent at code generation when I gave it well-structured prompts and clear site content. Within ten minutes of opening the editor I had a hero section that worked. Twenty minutes in I had a multi-page site with routing. The cost of "build me X" was essentially zero. I didn't pay for Lovable or any other site builder, and I could skip the learning curve on frontend frameworks entirely. What used to take a week now takes minutes.

A few things only become obvious once you start working with Claude Code.

  1. Claude is excellent at translating description into structure. I'd say something like "a section with a video background and overlay text," and what came back wasn't just a working block of code. It was a reusable Section component with a videoSrc prop, a separate VideoBackground component handling the cross-fade, and an overlay layered correctly on top. I didn't ask for any of that architecture. It just emerged sensibly out of the description, and most of it was the kind of decision an experienced engineer would have made on my behalf without telling me.
  2. Claude catches small details I would have missed. Halfway through the build I asked it to remove a section I no longer wanted, and on its own it also cleaned up the now-unused import statement at the top of the file. I wouldn't have thought about that if Claude hadn't shown me the edit. Each one of these moments is small in isolation, but over the course of a three-day build, dozens of them compound into a noticeable difference in velocity. The site moves forward faster than it would if I were watching every detail myself.
  3. Claude pushes decisions back to me. This was the part I valued most. When I described an interaction vaguely, Claude would often come back with three different options, lay out the tradeoffs between them, and ask which one I wanted. The pattern kept repeating throughout the build. I kept learning design principles from the process. And I genuinely enjoyed making the final calls. I started to see it as one of the more underrated parts of working with a good coding agent. The better the AI, the more decisions it puts in front of you.

Claude's strengths actually put more pressure on me to learn faster. If I want Claude to translate my descriptions into real structure, the descriptions have to be clear. If Claude is going to give me multiple options with tradeoffs, I have to know enough to choose between them. I'd rather not be the one slowing things down, especially when the coding agent keeps getting better.

What Claude Can't Do

Claude Code can build any UI you describe. It cannot tell you whether your UI is good.

Here's what kept happening. I described a section and Claude built it. It worked: buttons clicked, animations played, no console errors. Then I would look at it and know something was off, but I couldn't say what. I knew the result wasn't right. I just didn't have the vocabulary to point at the actual problem.

This is the same vocabulary problem from earlier, just on the other end. I had to borrow the words to describe what I wanted Claude to build, which is why motionsites.ai mattered. I also had to slowly build the words to describe what wasn't working in the result. That second gap was the real work. Each time I forced myself to answer "off how" (was the spacing wrong, the color too saturated, the text too dense, the hierarchy broken), I was building the vocabulary for what good actually looked like.

By Day 3 I could say "the cards are too dense, drop the background opacity by 30%" and Claude would do exactly that, and the result would be better. On Day 1 I would have just said "make it lighter" and had no way to know whether what came back actually was.

My take is that the AI-build wave doesn't eliminate the design-taste gap. It moves the gap earlier in the process. Before AI, that gap used to get filled in by the engineer working with you. They would build something, you would react, you would iterate, and over time their defaults plus your reactions converged on something that worked. Now there is no engineer between you and the output. Whatever you describe is what you get. If your description is vague, what comes back is the average of training data. You have to figure out for yourself why that isn't enough.

The Design Battles

Three places where the design-taste gap showed up most.

The article reading mode. I started with a single dark theme everywhere including the articles. Reading 12 minutes of an essay on a near-black background felt physically wrong. I added a light mode just for the article page, which showed cream paper, dark ink, navy links. Then I realized that landing on a bright page from a dark site was a retinal jump, so the article now defaults to a warm middle-gray that sits between the cinematic black of the rest of the site and the bright paper of a typical reading mode. The reader can toggle. This took six iterations and I'm still only 90% sure about it.

The cat video. I have a clip of my cat jumping out of a box. As a metaphor for "builder-PM leaving the corporate role," it's on the nose. Possibly too on the nose. I tried it as a full-bleed background of the About section. It looked weird because it was too literal and too distracting. I tried it as a square thumbnail in the middle of the layout, which turned out to be worse. It floated alone, with no narrative connection to anything around it. I ended up tucking it next to the "Reach out" CTA, where it also read as a small encouragement for the visitor to jump out of their own box and get in touch. The metaphor only lands once they've read the bio above it. That's the right place for it. It only took moving the video three times to figure that out.

The vertical line "rain." Late in the build I asked Claude for a subtle paper-grain effect on the article page. Drifting vertical strokes, like dust in a sunbeam. The first version was so subtle I literally couldn't see it. The second was too aggressive and looked like the Matrix. The third was the right density. The fourth was when I realized I wanted the rain constrained to the side gutters around the text, not behind it. Each iteration was 90 seconds of Claude rewriting the canvas code. The decision about what looked right took me much longer than 90 seconds.

Code is cheap, taste isn't.

What I'd Do Differently

If I were starting over, here's what I'd tell anyone building their personal site.

1. Run a consult-style session with an LLM about who you are and who this is for. Think of yourself as a product. Who is the user, what do they need to know about you in twenty seconds, and what do you want them to do next? Most of the work is asking yourself questions you've been avoiding, then letting the LLM push back on the answers. The output should be a written brief you can hand to the build session later.

2. Find a visual reference whose vocabulary fits. A template from motionsites.ai is a good starting point, especially if you read the prompt behind it, since the structure is reusable for any design direction. A screenshot of a site you admire works too. So does a Figma file you bought. Don't try to invent the design language during the build session. The build session is for execution.

3. Use real assets, not stock. I have my own snowboarding clip from Alaska, manta ray diving footage and a lava flow shot from Hawaii, a Monument Valley star trail photo. Each one is irreplaceable. No AI tool, no stock service can give you something only you have. The site feels like mine because of those assets, not because of the code.

4. Iterate visually before you iterate technically. Too many times, I asked Claude to refactor when I should have asked Claude to redesign. Code structure follows design intent. Get the design intent right first.

5. Show it to a few friends before you ship. I sent the staging URL to a small group of friends with different backgrounds (founders, engineers, designers) and asked them to react in their own words. Their first impressions caught things I had stopped seeing by Day 2. For previews, my suggestion is to pick people who will tell you the truth, not people who will tell you it looks great.

6. Ship before you're done. I deployed yihuisong.com when there was one MDX article with placeholder content, three "coming soon" essay slots, and a long open-decisions list. Deploying forced the questions I'd been deferring. What domain do I want? Should I use Vercel or Cloudflare? What email alias do I use? Most of those questions had 30-second answers once I had to answer them.

Why This Matters for Product Work

Product taste matters way more now as AI can write any code. The bottleneck has moved. It used to be "can we build this?" and now it's "do we know what we want?" The second question has always been the job of a PM, and the gap there is widening.

The through-line for anyone building AI products is the same. The product is the thing you can describe specifically enough that AI can build it well. Vague description, vague output. Specific description, specific output. The work of being specific, figuring out what good actually looks like in your domain, with your users, for your problem, is what didn't get cheaper. The two artifacts I made before the build, a positioning doc and a visual reference, weren't shortcuts. They were the work. Once I had them, Claude did the rest.

Building this site alone was practice, and I'll bring what I learned to the next thing I build with a team.