How to build a website with Claude Code
A step-by-step guide to building a website with Claude Code, from Paper designs to launch: the stack, the rules, previews and checks, using our own site.
- Written by
Matthew Bishop- Published
- Reading time
- 6 minutes
To build a website with Claude Code, start from finished designs, give it a clear stack and written rules, have it build reusable sections rather than pages, and review every change on a preview before anything goes live. We built superbrick.studio this way: from the first build to launch on its domain took five days in October 2026. Here’s the process, step by step, with the prompts we used.
This is the second of two guides. The first, how to design a website in Paper, covers the designs this one starts from.
What you’ll need
| Job | What we used |
|---|---|
| Designs and tokens | Paper, connected to Claude Code through its MCP server |
| Building | Claude Code |
| Framework | Astro, building static pages |
| Code and history | GitHub |
| Hosting, previews and feedback | Vercel, with comments on every preview |
| Forms | A small Vercel function that sends through Resend |
1. Choose the stack, in one prompt
Tell Claude Code what to build with, where the code lives and where the site is hosted. Our build started with one prompt:
“Can you build the website using the Astro framework, I want to host the code in Github and host on Vercel. Use paper’s design-to-code to help”
Astro builds plain, fast pages by default, which suits a marketing site. GitHub keeps every change in history, and Vercel turns every push into a preview you can review.
2. Write the rules down
An AI assistant won’t reliably remember last week’s decisions, so write them where it reads them at the start of every session. Ours live in three places:
- A project instructions file in the repository, with how to run and check the site.
- A README covering the structure, how content is added and how publishing works.
- Notes Claude reads each session: what’s confirmed and safe to publish, what’s confidential, and working rules such as “verify on the preview, never build locally”.
This is the step most people skip, and the one that saves the most time. Every rule written once is a correction you never make again.
3. Bring the designs in as values, not pictures
With Paper connected, Claude reads the designs directly: each element’s structure and its computed styles, not a screenshot to copy by eye. Two habits made the biggest difference:
- Export the tokens, don’t retype them. Our colours, type and spacing came out of Paper into one stylesheet, with a rule to re-export rather than hand-edit.
- Read values, never guess them. Sizes, spacing and colours come from the design file, so there’s nothing to approximate.
4. Build sections, not pages
Have Claude build each band of a page as a reusable section component, with the words kept in data files rather than in the markup. A new page is then assembled from sections that already work, and changing a heading or a quote never means touching layout code.
Our first build of four pages took about 20 minutes. We then measured it against the Paper designs at desktop width: the Work page matched exactly, Services was 2 pixels out and Home 6.
The same idea scales. When we added case studies, every study used one shared template, so nine were added in three days and a fix to one fixes them all. The journal posts are plain Markdown files with a schema, so adding a post never touches the code.
5. Review every change on a preview
Never review on your own machine. Push every change to a preview, a private copy of the site at its own address, and leave feedback on the page itself with Vercel’s comments (Vercel):
“can you add the vercel toolbar”
“made some comments with vercel”
Claude reads the comments, makes the changes and pushes a new preview. Publishing stays a separate, deliberate step, only when you say so. Two safeguards are worth building in early:
- Keep previews out of search. Only the production build should be indexable, so a preview can never compete with the real site.
- Let drafts build on previews only. New pages can be reviewed at their real address without appearing on the live site.
6. Polish with small, specific prompts
Most of the finish comes from short prompts with one clear outcome:
“can we add some animations? Can we stagger animations, but I want a blur fade in effect”
“i dont want slide up at all, but I want more blue”
Say what you don’t want as well as what you do. Correcting one thing at a time keeps each change easy to review.
7. Wire up the parts visitors don’t see
Before launch, make sure everything behind the pages works:
- Forms. Ours started on a third-party form service that was slow to deliver, so they moved to a small function that sends each enquiry through Resend straight away.
- Analytics and consent, checked on the preview.
- Search basics: titles, descriptions, a sitemap, structured data and redirects for any old addresses.
8. Launch, and check it
“can you launch on superbrick.studio domain”
Our site was live on its domain 18 minutes later, on 7 October 2026. On launch day it scored 100 for SEO and best practices in Lighthouse, 95 to 100 for performance on mobile, and 96 for accessibility. In its first nine days the repository had 240 commits, almost all of them small changes reviewed on a preview first.
What we learned
- Check assets the way the page shows them. An image optimiser stripped a setting from our SVG logos and every client logo cropped on the live site, even though a check of each file on its own had passed.
- Real screens beat generated scenes. AI-generated photos of laptops on desks looked like stock photography. We use real screenshots in browser frames, built in code.
- Make the server require exactly what the form does. A server that required a field the form didn’t turned real enquiries away.
- Let animations settle before you capture. Screenshots taken mid-animation look broken.
When a site built this way suits you
We build client websites both ways. A site built as code, like ours, suits teams who want full control over design and performance, and who are happy to ask for a change and check it on a preview. Generate’s site works this way: its team asks an AI assistant for changes and checks each one on a preview before it goes live. Teams who want to edit pages visually, themselves, often suit Webflow, and we build those too (how we help teams choose).
Questions we get asked
Can Claude Code build a whole website?
Yes, with a person directing it. Claude Code built our site from Paper designs, but every decision about design, copy and what went live was ours. It works best with finished designs, written rules, small specific prompts and every change reviewed on a preview.
How long does it take to build a website with Claude Code?
Ours took five days from the first build to launch, after the designs were set up in Paper. The first four pages took about 20 minutes; most of the time went into review, polish, content and the parts visitors don’t see.
Do you need to know how to code?
You need to know what good looks like, and someone who can review what’s built. We direct the work, check every change on a preview and decide what ships. That judgement matters more than writing the code yourself.
Can our team update a site built this way?
Yes. Content lives in plain files rather than in the page code, and changes go to a preview first. Generate’s team updates its site by asking an AI assistant for a change and checking it on a preview before it goes live.
If you’d like a site built this way, see our custom website development, or tell us about your project.
