How to ship a one-page website with Claude, v0, and GitHub in 90 minutes

Okay, here’s the actual mechanic. These tools charge you per message, and every message drags your entire codebase along with it as context. On an empty project that’s basically nothing. On a finished site it’s every component you’ve built.

So message fifteen isn’t priced like message one. It’s priced like message one plus your whole project. And it gets worse every time you add a section.

Treat it like a design partner and you’ll pay for the privilege. Treat it like a one-shot scaffolder and you’ll barely spend a thing.

Once that clicks, everything else falls into place around one move.

Do the thinking where thinking is cheap. Hand it one finished spec. Build once. Leave. Edit locally.

Four tools, four jobs. The entire trick is not letting them do each other’s homework.

So the rule is simple: if you can say the change out loud, it belongs in the chat, not the builder.

Start in Claude. Not in v0. Answer these six questions in one message. Short answers are fine, just be specific.

1. 01Who is this page for, and what do they need to believe by the time they hit the bottom?
2. 02What’s the one thing you want them to do?
3. 03What are the three to five things that have to be on the page?
4. 04What do you already have? Logo, colors, fonts, photos, or nothing yet.
5. 05Name two sites you like, and one sentence on why for each.
6. 06Do you have a domain?

Then ask for a build spec, not a website. Four things: the section-by-section outline, the design tokens as actual values instead of adjectives, what every button does, and the copy written out in full. If you already have a brand kit, the tokens come straight off it.

The copy is where the money is. Hand the builder no words and it’ll invent some, and every “no, fix that headline” after that is another paid message. Writing it in the chat costs you nothing.

Rip the spec apart as much as you want here. Every fix you make now is a paid message you never send.

Ask Claude to build the whole page as one static HTML file using your tokens. No framework, no build step. Open it in your browser and react to it.

You’re going to delete this file, and it’s still the most valuable ten minutes of the whole build. It turns “I’ll know it when I see it” into something you can actually point at, while pointing is still free. Shove it around until you like it.

Then screenshot it. That screenshot tells the builder more about the look you’re after than three paragraphs of adjectives ever will, and it costs a fraction as much to send.

New chat. Attach the screenshot. Paste one prompt with the whole spec in it: the outline, the copy word for word, the tokens, and a list of constraints that heads off the usual rework.

Then stop. Seriously, stop. Judge what comes back on three things and nothing else. Is the structure right? Is the copy right? Is it close enough that a bit of local polish finishes it?

Close enough is the goal. Perfect inside the builder costs money. Perfect on your own machine costs nothing.

One follow-up is fair if something structural is missing, like a whole section. If you’re typing a third, your spec was too thin. Start a fresh chat with a better one instead of patching, because a new chat on an empty project is cheaper than message six on a full one.

Use v0’s GitHub option to create the repo, then pull it down and run it.

git clone <repo-url>
cd <repo-folder>
npm install
npm run dev

From here, GitHub is the truth and you stop opening v0. Go back later and it edits a version of your code that doesn’t match your repo anymore, and now you’re merging two realities by hand. That’s a bad afternoon.

On your machine, with a coding agent in the project folder. Spacing, how it behaves on a phone, hover states, copy tweaks, favicon, page title, meta description, alt text, contrast. This is the fun part, and it’s also where the work stops costing you per message.

Two habits do most of the work here. Batch your feedback: walk the whole page, write down all twelve things, hand over all twelve at once, because twelve separate asks cost far more than one list of twelve. And actually look at the page before you call it done. An edit applying cleanly isn’t the same as it working.

Commit as you go. Small commits are your undo button.

Vercel: New Project, import the repo, Deploy. About a minute later you’ve got a live URL. Custom domain goes in the project settings and it walks you through the DNS.

After that, git push is the deploy. That’s it. That’s the part that makes this whole setup worth keeping. One thing to check once your domain is connected: which domain your site tells Google to index, because connecting a domain is exactly when that goes wrong.

1. 01Never ask the builder something the chat could answer. Strategy, copy, naming, color, all of it belongs in the free room.
2. 02Show, don’t describe. One screenshot beats a paragraph of adjectives and costs less.
3. 03Never rebuild for a small change. Color, padding and wording are local edits.
4. 04One direction, not three. Asking for variations multiplies your bill. Explore in the mock instead.
5. 05Set your constraints up front. No lorem, no external image URLs, no backend, one page.
6. 06Kill a bad chat early. Whatever you’ve already spent is spent, and starting clean is almost always cheaper than pushing through.
7. 07Save the spec. It’s what makes site number two take 45 minutes instead of 90.

These are the actual ones we use. Take them, they’re yours.

I'm building a one-page website. Help me write a build spec I can hand to v0.

Audience: [who]
Goal: [the one action]
Must include: [3-5 things]
Brand assets: [logo/colors/fonts/photos, or "none yet"]
References: [2 sites + why]
Domain: [or "none yet"]

Give me back:
1. Section-by-section outline with the purpose of each
2. Final copy, written out, for every headline, paragraph, and button
3. Locked design tokens: hex colors, font pairing, radius, spacing scale
4. What every interactive element does

Then build the whole thing as a single static HTML file I can open in a
browser, using those exact tokens, so I can react to it before I spend
any v0 credits.

Build a single-page marketing site. Next.js App Router, TypeScript,
Tailwind, shadcn/ui. Match the attached screenshot for layout and style.

SECTIONS, in order:
[paste outline]

COPY (use exactly this, do not rewrite or add filler):
[paste final copy]

DESIGN TOKENS:
Colors: [hex list, with roles]
Fonts: [heading / body]
Radius: [value]  Spacing: [scale]

REQUIREMENTS:
- One page, no routing, no backend, no auth, no database
- One component file per section, composed in app/page.tsx
- Responsive, mobile first
- No placeholder or lorem text anywhere
- No external image URLs; use solid color or gradient blocks where a
  photo will go later
- Semantic HTML, accessible contrast, alt text on everything

This is built for one page. Push past five or six and the math flips: the codebase riding along in every message grows faster than the next build is worth, and you’re better off scaffolding once and doing the rest by hand.

It also assumes no backend. The second you need logins, a database, or payments, the builder stops being the fast path, and the stuff it quietly gets wrong is exactly the stuff that’s expensive to get wrong.

And TBH? If that mock from step two is already the site you wanted, skip the builder entirely. Scaffold it locally, push it, deploy it, spend nothing. A builder earns its spot when you want a polished starting point you wouldn’t have thought of, or real production React instead of a hand-rolled page. For a genuinely simple one-pager, that’s a real choice, not an automatic yes.

Also: pricing and plan names on these tools change constantly. The mechanics here hold up. Go check the current numbers yourself before you budget around them.