Prove Your Demo Site Before the Pitch

Prove Your Demo Site Before the Pitch

A pitch is not a launch gate: the room will open one URL, on one path, under live screen-share pressure. Static polish checklists and done-for-you demo services catch visual hygiene; they do not run Census-derived personas through the exact journey you will narrate. Boidwatch runs a capped peek or --quick flock in real Chromium against that demo URL with your pitch script as design intent, then returns a shareable report with a public link—no investor or client account. Paste the strongest finding and public link into the deck or pre-meeting note; escalate to a full flock only when the packet needs the teardown. This does not guarantee a live pitch “won’t break”—it gives you a visitor-proof artifact on the URL you will open.

Why pitch ≠ launch checklist (and ≠ builder handoff)

Three jobs get conflated before demo day. Keep them separate.

Launch / client handoff checklists (Test the site before client handoff) own pre-delivery gates when a client takes ownership: frozen URL, static hygiene, primary journey, persona layer in the handoff packet.

Builder handoff (Prove a Lovable, Bolt, or v0 site before client handoff) owns published-URL proof after Lovable / Bolt / v0 / similar—builder-native checks plus cold-visitor flock before the client opens the share link.

Pitch / demo-day owns the screen-share moment: one URL, one path, live narration, no redo mid-call. The artifact belongs in the deck slide or pre-meeting note—not only in a delivery SOW.

The gap SERP checklists miss: proof that Census-weighted strangers can finish the path you will narrate, with a public report link you can drop next to the agenda. Adjacent framing: Agent-native shipping proof (peek before the client link) and Client-ready UX teardown for agencies (when the packet needs a billable teardown).

Lock the demo URL and path

Point the flock at the exact URL and path you will open—pricing → Book demo, waitlist submit, checkout stub, investor story homepage → product → pricing—not a random homepage load while you “click around.”

Staging vs production. Match what the room will see: auth state, seed data, feature flags, demo accounts. A green pass on yesterday’s staging clone does not prove today’s pitch host.

Reachability. Password walls, IP allowlists, and bot challenges block headless Chromium. Boidwatch exits 2 with REACHABILITY_ERROR, creates no run, and charges no credits (see llms.txt). Open the demo URL for the flock (or use a reachable staging clone of the same path), then re-run. Exit 2 is reachability—not “the pitch UX failed.” Exit 9 covers assert / entry-block failures on a run that did start.

The three-layer gate before you share the screen

Layer 1 proves the slide looks clean. Layer 2 proves the project/deploy is intact. Layer 3 proves strangers can finish the pitch path on the URL you will open. Mixing them is how teams ship “polish checklist green” and still stall on Book demo under live narration.

How to run Boidwatch with the pitch script as design intent

Authenticate with an API key (API keys settings). New accounts get 30 free credits (1 credit = 1 persona). Paste the demo URL and encode the pitch script as design intent—one line the flock should try to finish.

Examples of design intent:

• screen-share path: homepage → pricing → Book demo
• land waitlist, submit email with company domain
• investor story: homepage → product → pricing

Prefer documented CLI / MCP for the deliverable. Adjacent shipping gate: authenticated POST /v1/peek on https://api.boidwatch.com (3 personas, 15 steps, 5-minute hard stop → one strongest finding; full report gated). Prefer CLI --quick / MCP until peek appears in public llms.txt—same caveat as AI website QA with real browser sessions and MCP site QA for Cursor and Claude Code. CLI and MCP create ordinary /v1/runs, not peeks.

export BOIDWATCH_API_KEY=fg_live_...

# Cost preview only — no flock
boidwatch --json run create \
  --url https://DEMO-URL \
  --design-intent "screen-share path: homepage → pricing → Book demo" \
  --quick --dry-run

# 5-persona credit run; wait for compact JSON
boidwatch --json run create \
  --url https://DEMO-URL \
  --design-intent "screen-share path: homepage → pricing → Book demo" \
  --quick --wait

Cap choice. Peek for the strongest blocker before the call. --quick (5 personas / 5 credits) when the note needs a small flock. Drop --quick for a full flock (default 20 personas) only when you need the teardown packet. Those counts and ungated complete reports require wallet top-up / a paid run outside the free cap. Without top-up, ordinary runs remain free-capped at 3 personas with gated results, even with signup credits. Agents can introspect flags and exit codes with boidwatch commands.

MCP when an agent is already in the prep loop (MCP site QA):

claude mcp add boidwatch
# then call boidwatch_quick_check (~45s) with the demo URL + design intent

Install (CLI v1.1.0+):

curl -fsSL https://boidwatch.com/install.sh | sh
# or: brew install boidwatch/tap/boidwatch

What goes in the deck slide / pre-meeting note

The room needs a decision artifact, not a JSON dump.

Include:

• The demo URL and path that were proven
• One-line design intent (the pitch script)
• Strongest friction finding (severity + short description) and fix / accept / escalate
• Public Boidwatch report link (no investor or client account)

Do not include: raw --json stdout, full persona transcripts, or credit burn unless finance asked.

Narrate it in one line the room can skim: “Persona flock on the URL you’ll open found X; we fixed Y before the call—report: \.” That is the slide / note packet. Related deliverable shape when you need a billable teardown: Client-ready UX teardown for agencies.

Honest comparison posture

Choose by job.

Never claim Boidwatch “replaces” Afterbuild, Underlabs, or a human demo-polish retainer. Keep polish when you need polish. Add the persona flock when the risk is strangers failing the path under live narration—not only whether the favicon and mobile crop look clean.

FAQ

How do I prove an AI-built demo site won’t break during a client or investor pitch?

You cannot guarantee a live pitch. You can lock the exact URL and path, finish static polish and any builder/deploy checks, then run a persona peek or --quick flock with the pitch script as design intent. Paste the strongest finding and public report link into the deck or pre-meeting note before the room opens the tab.

What’s the difference between a launch / handoff checklist and a pre-pitch pass on the URL I’ll screen-share?

Launch / handoff checklists own pre-delivery ownership transfer. Builder handoff owns published-URL proof after an AI builder. Pre-pitch owns the screen-share moment—one URL, one path, live narration—with a proof artifact that belongs on the slide or in the pre-meeting note.

Which URL and path should I point Boidwatch at before demo day?

The exact URL and path you will open in the room (for example pricing → Book demo), matching staging/production auth and seed data the audience will see. If password walls or bot protection block Chromium, expect exit 2 (REACHABILITY_ERROR) with no credits charged; open access and retry.

What should go on the deck slide or in the pre-meeting note as proof?

Demo URL + path, one-line design intent, strongest friction finding + decision, and the public Boidwatch report link—not raw JSON and not a vague “AI QA passed” line.

Paste tomorrow’s pitch URL into a peek

Before tomorrow’s pitch, paste the exact URL and path you’ll screen-share into a capped peek (or --quick flock) with the pitch script as design intent; drop the strongest finding and public report link into the deck slide or pre-meeting note.

boidwatch --json run create \
  --url https://DEMO-URL \
  --design-intent "screen-share path: homepage → pricing → Book demo" \
  --quick --wait

Product: boidwatch.com · agent docs: llms.txt · web app: app.boidwatch.com · keys: API keys settings.