6.2 Build: Idea to Live Site

You shipped your quick win in 4.5. Now we make it repeatable — an idea-to-review-surface workflow you can test for yourself, an authorized organization, or a potential client. The process can become evidence for an offer; it does not establish demand or income by itself.

What you will learn

• Run the full site-build recipe: discovery → scaffold → build → content → polish → deploy.
• Use session boundaries and the second brain across a multi-session build.
• Deliver something a real client would accept — including the parts that aren't code.

Builder principle

Amateurs build pages. Professionals run a process that reliably produces pages. Sell the process to yourself first.

The recipe

Six phases, each banked before the next. Estimate each phase from your scope and revise the schedule after discovery; do not promise a same-day or weekend delivery before the content, access, and review constraints are known.

Phase 1 — Discovery (no agent, 20 min)

The unskippable part. For a real subject — you, a friend's business, a community org:

Data gate — complete before recording discovery

Classify the content; confirm the subject authorized its use with the agent and its tools; check provider, account, retention, and organizational rules; remove unnecessary personal or confidential details; and use a synthetic subject when any answer is unclear. Public deployment requires separate approval for every real name, image, testimonial, and contact detail.

WHO: (the subject, in one paragraph)
VISITORS: (who lands here, and what they should DO — call? book? trust?)
PAGES/SECTIONS: (the minimum honest set — usually 4-6 sections, one page)
VIBE: (three adjectives + 1-2 example sites whose feel is right)
CONTENT I HAVE: (photos? bio? testimonials? — inventory reality)
NOT THIS TIME: (the scope-killer line, as always)

Save as docs/discovery.md in a fresh project folder. This file is the build's constitution — every later session reads it.

Phase 2 — Scaffold (one session)

New repo, CLAUDE.md, second-brain skeleton (you know this drill cold now), then:

Read docs/discovery.md. Plan a single-page site structure for it:
sections in order, and for each — its job and rough content needs.
Plan mode; I want to negotiate before we build.

Negotiate with the four questions (4.2). Decisions → docs/decisions.md. /wrap, clear.

Phase 3 — Build (one session, the big one)

Read docs/discovery.md and docs/decisions.md. Build the site per the
agreed structure with placeholder content marked clearly as PLACEHOLDER.
Style per the VIBE line. Done means: every section present, responsive
at 375px, zero placeholder styling — only placeholder text.

Structure first, real words later — content decisions contaminate layout decisions when made simultaneously. Verify the skeleton at phone width now; layout bugs are cheapest before content moves in.

Phase 4 — Content (one session)

The differentiator between "template" and "theirs":

Re-run the Phase 1 data gate before adding real content or a voice sample. If authorization or provider handling is unclear, keep the placeholders and use synthetic copy.

Replace placeholders using docs/discovery.md's real content inventory.
For missing pieces, draft copy in the subject's voice — here's a
paragraph of how they actually talk: [paste an approved or synthetic sample].
Never invent facts: no fake testimonials, no invented years-in-business,
no stock claims. Where facts are missing, leave TODO(owner) markers.

That no-invented-facts clause is ethics and quality — invented specifics are hallucination invited in the front door (2.4). Real voice + real facts is what makes a site feel human.

Phase 5 — Polish (one session)

Quality pass, in order: 1) rude-test the whole page — empty states,
long names, tiny screens, slow connection behavior. 2) Consistency —
spacing, colors, hover states. 3) The details that signal care:
favicon, page title, social preview text, footer. Show me a before/
after list of what you changed.

Then run the accessible human-acceptance matrix on a device you can access. A second reviewer can add useful evidence, but share the preview only with an authorized person and label any delegated visual review honestly.

Phase 6 — Deploy + handoff (one session)

GitHub Pages as in 4.5. But professionals ship two artifacts, not one:

The site is approved and live. Write HANDOFF.md for a non-technical
owner: what this site is, the URL, how to request changes, what each
file is in one line, and the three most likely future updates with
rough effort estimates.

That handoff doc is what separates "my nephew made me a site once" from a professional deliverable — even when the client is you.

🌱 No-code lane⚙️ Engineer lane

Run the recipe on build #2 from your Lesson 1.4 list or an authorized synthetic/real subject. After multiple comparable runs, you can evaluate repeatability, support cost, and whether a specific user would pay for it.

Test whether the phases transfer to your stack; a service or internal dashboard will add architecture, security, data, and operations work beyond a static site. Useful candidates to retain are discovery as a file, structure-before-content, and the handoff artifact.

Try it now

Run the full recipe on an authorized real or synthetic subject. Bank the six phases between sessions. When the result is reviewable, add the public-safe URL, private recording, or local artifact and the measured process notes to your journal.

Check your understanding

• Why does discovery happen without the agent, and what file does it produce?
• Why structure before content, mechanically?
• What's the no-invented-facts clause guarding against, in Chapter 2 terms?
• What two artifacts does a professional deploy produce, and who is the second one for?