Your first build

Enough theory. This page takes you from an empty folder to a real page running in your browser, committed to GitHub, in about an hour. Do it with your hands, not by reading.

We're deliberately building something you can judge with the skills you already have: a landing page. You know what good spacing looks like. You'll be able to tell immediately whether the AI did what you asked — which makes it the perfect first project.

Step 1 — A folder and a plan

Make a folder, open your tool in it, and — this is the bit people skip — write down what you want before you ask for anything.

mkdir -p ~/projects/first-build
cd ~/projects/first-build
claude

Now, in plan mode (Shift+Tab), describe the page. Not "make me a landing page" — that gets you the generic purple gradient thing everyone gets. Describe it the way you'd brief a designer:

A one-page marketing site for a fictional product: a booking tool
for independent dog walkers.

Sections, in order:
1. Nav: logo left, three links right, one "Get started" button
2. Hero: big headline, one supporting sentence, primary + secondary
   button, and space on the right for a screenshot
3. Three feature cards in a row (stacked on mobile)
4. A simple two-column "how it works" with numbered steps
5. Footer: logo, three link columns, copyright

Style: clean and calm. Lots of white space. One accent colour
(a muted green), near-black text on off-white, no gradients,
no drop shadows except a very subtle one on the cards.
Type: a serif for headings, a system sans for body.

Plain HTML and CSS in two files. No frameworks, no build step.
I want to be able to open index.html directly in my browser.

Read the plan it gives you. Change at least one thing about it. Then approve.

Step 2 — Look at it properly

Open index.html in your browser. Then do these four things, in this order, every single time you build anything for the rest of your life:

1. Look at it on desktop. Is the hierarchy right? Is the spacing consistent?
2. Squash the window narrow. Does it survive? This is your mobile check and it takes two seconds.
3. Click everything. Every link, every button.
4. Read the words. AI-written copy is nearly always too long and slightly hollow.

Step 3 — Refine like a designer

Now use your actual expertise. Vague feedback gets vague results; specific feedback works extremely well:

Step 4 — Commit, before you like it

The page works. Commit now, before the next round of changes:

git init
git add .
git commit -m "First version of dog walker landing page"

Then push it to GitHub as a private repo — either through GitHub Desktop, or just ask the AI to walk you through it. Now every experiment from here is free.

Step 5 — Break it on purpose

Here's the exercise that teaches more than the first four steps combined. Ask for something ambitious and slightly silly:

Redesign this entirely as a brutalist site: heavy black borders,
one loud accent colour, oversized type, hard edges, no curves.
Keep the same content and structure.

You'll get something dramatic. Maybe good, maybe hideous. Doesn't matter — git restore . and it's as if it never happened. That feeling is the thing to internalise. Version control turns experiments into free actions, and founders who grasp this move several times faster than ones who don't.

Common first-hour problems

I'm a founder with design experience but not much coding experience. I want to build [describe the page or app] and I want it to look considered rather than like generic AI output.

Interview me to build a proper design brief. Ask me about, one question at a time:
- The feeling the product should give (pick three adjectives, and three it should NOT give)
- Two or three existing sites whose visual approach I admire, and specifically what about them
- My colour direction, and whether there's an existing brand to respect
- Type: serif or sans for headings, and how loud the type should be
- Density: airy and spacious, or compact and information-dense
- What the user should notice first on the page

Then write me a design brief I can paste at the start of any future prompt — including explicit "do not" rules, a spacing scale, a type scale, and a short colour palette with hex values. Keep it under 400 words so it's practical to reuse.

Act as a senior product designer reviewing this page. Look at the actual HTML and CSS in this project.

Give me:
1. The three most damaging visual problems, in priority order, each with the specific CSS change that fixes it.
2. An audit of my spacing: am I using a consistent scale, or arbitrary values? List every distinct margin/padding value currently in use.
3. An audit of my type: how many font sizes and weights am I using? Is that too many?
4. Anything that will break or look wrong between 360px and 1440px wide.
5. Three things that are genuinely good and I should keep.

Be specific and critical. Don't rewrite anything yet — I want the review first, then I'll pick which fixes to apply.

Review this page for accessibility, explained for a founder who cares but doesn't know the standards.

For each issue found:
- What's wrong, in plain English
- Who it actually affects and how (be concrete — not "screen reader users" but what they'd experience)
- The fix
- Whether it's a must-fix before launch or a nice-to-have

Check at minimum: colour contrast on every text/background pair (give me the actual ratios), heading order, keyboard navigation and focus states, alt text, form labels, and whether anything relies on colour alone to convey meaning.

Then show me how to check these myself in future using only the browser's built-in tools.