Validation before code

Principle

Validation answers one question: will a specific human take a specific action under real constraints? Not “is this a good idea?” Not “can we build it?” Not “does the demo look finished?”

The cheapest validation is often not code — a landing page with a sharp promise, a manual service behind a form, a paid pilot with a spreadsheet backend. AI helps you design and run these fast; it does not replace counting outcomes.

The decision

  Problem bet
│
▼
Smoke (hours) ──► fail ──► revise or kill
│ pass
▼
Concierge (days) ──► fail ──► revise or kill
│ pass
▼
Vibe prototype (Chapter 06) or thin code slice

Experiment ladder

AI can draft copy, generate variants, and summarize results. You set the success threshold before you launch.

Workflow

1. Write the hypothesis — “At least X of Y people will Z within N days.”
2. Pre-register success and kill — numbers, not feelings. Example: 5 waitlist emails from 100 targeted visitors in 7 days, or kill.
3. Pick the lowest rung that could falsify the bet.
4. Ship the experiment — one channel, one audience, one CTA. No feature creep.
5. Count — spreadsheet: date, source, action, notes.
6. Revise the bet — promote to shape (vibe), another experiment, or graveyard.

What AI is good for here

• Landing copy variants from your problem one-pager
• Outreach drafts to a defined list (you send; you track replies)
• Parsing results into a table — still verify against raw exports
• Post-mortem: “what did we learn?” with links to evidence

What AI cannot validate

• Whether strangers trust you — that is behavior over time.
• Whether unit economics work — you need real price and cost.
• Whether the workflow survives Tuesday — repeat use beats launch day applause.

Tooling

Carrd, Framer, or a single Astro page for smoke tests. Stripe payment links for paid concierge. Typeform or plain email. PostHog or Plausible for counts — or a manual tally if traffic is small.

Common mistakes

• Building the product to validate demand — you validated your building speed, not the market.
• Moving goalposts when numbers disappoint.
• Measuring compliments at demo meetings instead of signed-up emails.
• Running five experiments at once — you learn nothing about causality.

Artifacts

• templates/validation-experiment.md — hypothesis, threshold, channel, count sheet.
• Graveyard entry when killed — what failed, what you’d try next time.

Scenario (composite)

A two-person team believed accountants at mid-size firms would pay for automated expense categorization. They skipped validation and spent two weeks on a demo dashboard with synthetic data — three LinkedIn posts produced polite comments, zero signups with an email field.

They restarted with a smoke test: one-page promise, book-a-15-minute call CTA, 120 targeted outreach messages over five days. Four calls booked; two described the problem in detail but would not pay until compliance features existed. Kill threshold was five paid pilot commits in fourteen days — they revised the bet toward compliance-first concierge, ran a manual categorization service for one client at a fixed weekly fee, and got one renewal before writing app code.

The lesson: the first build validated building speed; the concierge validated workflow pain and price sensitivity.

Falsify this

• Your “validation” is a demo friends admired — no pre-registered threshold, no strangers counted.
• You are measuring meetings scheduled, not money or repeat actions.
• Escalating to code because smoke “felt slow” — when the real signal is weak positioning, not tool limits.
• You ran a landing page but changed the promise mid-week — the count is not comparable.
• Validation passed on Tuesday enthusiasm that did not repeat by the following week.

Further reading

• Chapter 02 — Finding problems worth building
• Chapter 03 — Discovery and research with AI
• Chapter 06 — Vibe prototyping (after validation passes)