How I Built My Website With Claude as a Product Manager

TL;DR by Goose▾

Ingredients

• Claude — the AI that wrote the code ($200/yr)
• Next.js — the framework the site runs on (free)
• Vercel — hosting that redeploys every time you save to GitHub (free)
• GitHub — stores the code; Vercel sets it up for you (free)
• VS Code and Terminal — where you edit files and run commands (free)
• Node.js — runs a preview of the site on your own computer (free)
• A domain name — bought from any registrar (roughly $10–20/yr for a .com)
• Cloudflare — manages where the domain points (free)
• Google Forms and Google Analytics — a first contact form and visitor stats (free)

Why a Product Manager Built a Custom Site Instead of Using a Template

I wanted a personal website that felt like mine. Website builders make things easy by handing you boxes to fill in: a header here, a bio there, a contact form at the bottom. The result works, but it looks like everyone else’s. I wanted my own typography, my own colors, a layout I’d designed, and a place for writing that felt intentional.

The catch: I’m not a full-time developer. I can read code, work in a terminal and reason about how systems fit together, but writing a whole site from scratch isn’t my day job, and hiring someone for a custom site costs thousands of dollars. What changed is that AI can now write working code, not just snippets. So the real question became: how long does it take someone who isn’t a full-time developer to build a custom website with Claude? This post is my answer.

Session 1: Setting Up a Next.js Site

Evening, Day 1 — ~3 hours

The first hour wasn’t design at all. It was getting the right tools onto my computer: a code editor, a terminal, and a live preview of the site running locally. Vercel made the start painless: one click created a blank Next.js site, put it online, and connected it to a new GitHub repository.

Then I copied the project to my laptop and tried to start the preview. It failed right away, which turned out to be the most normal thing in the world:

With the preview running, I described the look I wanted to Claude and shared screenshots of sites I admired. Claude wrote the complete layout, typography, and color files. I dropped them into the project folder, and my design appeared in the browser.

🔧 Developer section: the setup, step by step

• Create a Next.js project from Vercel’s dashboard; it creates and links the GitHub repo
• Clone the repo, open it in VS Code, and run npm install before npm run dev
• Ask Claude for full files (page.tsx, layout.tsx, globals.css), not snippets. Replacing whole files is easier than splicing
• If a pasted file shows up empty, check that it actually saved before debugging anything else

How the Site Goes Live: Laptop → GitHub → Vercel

Before building pages, it helps to understand the path your code takes to the internet, because you’ll use it dozens of times. There are three stops. Your laptop is where you write and preview. GitHub stores every saved version. Vercel watches GitHub, and every time you push a change to the main branch, it builds the site and puts the new version online, usually in under a minute.

You set this up once. If you start from a Vercel template, as I did, Vercel creates the GitHub repository and connects it for you. If you already have a project on your laptop, create an empty repository on GitHub (private is fine), push your code to it, then use Vercel’s “Import Project” button to connect that repository. Either way, you end up in the same place: push to GitHub, and the site updates.

🔧 Developer section: the first push, and every push after

• Pushes to main go live. Pushes to any other branch get their own preview URL, which is a safe place to check a change before it ships
• Keep secrets (API keys, passwords) in a local env file that git ignores, never in the code
• Anything your site reads from that env file also has to be added in Vercel’s project settings. Vercel builds from GitHub, so it can’t see files that only exist on your laptop

Session 2: Building the Pages With Claude

Day 2 — ~2–3 hours

This was the fastest stretch. For each page (About, Work, Contact), I described what I wanted in plain English and got back a complete, styled page. I added my own photos, saved, and pushed to GitHub. Vercel had each change live in about 30 seconds.

The contact form started simple: a Google Form embedded in a styled page, with email alerts turned on in Google Forms. No code needed. (I later replaced it with a custom form.)

Then I opened the site on my phone, and it was broken. The desktop layout hadn’t translated: headline text cut off, the hero image clipped, and the tiles squeezed into a grid that didn’t fit.

Session 3: Buying a Domain and Connecting It

Day 2 — ~45 minutes

Until this point the site lived at a free Vercel address. The last session was mostly settings, not code: buying a domain and pointing it at the site.

Step 1: Pick and buy a domain

Any domain registrar works, and a .com typically runs about $10–20 a year. Pick something short that you’d be happy to say out loud. Watch for first-year discounts that renew at a much higher price, and turn on auto-renew so the domain can’t lapse.

You’ll also choose between the bare domain (yourdomain.com) and the www version (www.yourdomain.com). Both should work, but one should be the “real” address, with the other redirecting to it. I made the bare domain the real one and redirect www to it. Having a single address matters later, because Google treats the two as separate sites unless one redirects to the other.

Step 2: Add the domain in Vercel, then copy its records to your registrar

In your Vercel project, go to Settings → Domains and add your domain. Vercel then shows you the DNS records it needs, usually two: one for the bare domain and one for www. Log in to wherever your domain’s DNS is managed (your registrar, or a DNS service like Cloudflare) and add them, copying the values exactly as Vercel displays them.

Step 3: Wait, then check

DNS changes can take anywhere from a few minutes to a few hours to spread. Vercel’s Domains page shows a green check once it can see your records, and it sets up HTTPS (the padlock) on its own. Check the site on your phone as well as your laptop, using both the bare and www addresses.

Analytics came last: one package install and a single line in the site’s layout file. I watched myself show up as a live visitor within 30 seconds.

The one real snag: after moving the domain to Cloudflare, the site stopped loading on my phone. Two things were wrong. One of the domain’s records still pointed at the old host, and Cloudflare was set to route traffic through its own network on top of Vercel’s. Pointing the record at Vercel and switching Cloudflare to “DNS only” fixed it immediately.

How Hard Is It Really? A Second Opinion From Gemini

After writing this up, I wasn’t sure I was being honest about the difficulty. It’s hard to grade something you just did. So I gave the write-up to a different AI, Google’s Gemini, and asked it to grade the difficulty independently, since Claude had built the site and would have an obvious bias.

• Easy: generating the design and pages with Claude, deploying with Vercel and GitHub, and the Google Forms and Analytics setup.
• Moderate: the local setup (installing tools, using the terminal) and the back-and-forth of mobile fixes.
• Tricky: connecting a custom domain across three services.

Gemini’s verdict: beginner-friendly if you’re comfortable following a tutorial and not afraid of a terminal window. The takeaway I agree with most: the work isn’t writing code, it’s patiently fixing the small errors that show up during setup and domain linking.

What It Took to Build a Website With AI

A custom personal website on its own domain, working on desktop and mobile, with four pages, a contact form, and analytics, built in about 6–7 hours by a product manager who isn’t a full-time developer.

What went fast

• Going live. Vercel put the first version online in one click, and every push after that deployed itself.
• Building pages. Each one took minutes to describe and generate.
• Analytics. One install, one line of code.

What needed patience

• First-time setup. Installing tools and learning the few commands you actually need.
• Mobile. Several rounds of fixes before it looked right on a phone.
• The domain. Three dashboards that all had to agree.

The biggest lesson: shipping a website isn’t one skill, it’s a dozen small ones strung together. Claude handled the code. I handled the decisions. And Goose supervised from the couch.