Boidwatch ← All posts

Test the Site Before Client Handoff

Before handoff, complete the primary visitor journey on staging, catch static breakages (links, forms, console, metadata), and attach evidence—not “looks good.” Boidwatch adds a persona flock in real Chromium sessions against your design intent and returns a client-ready report with a public link you can paste into the handoff note. Use a capped peek (3 personas, 15 steps, 5-minute stop) when you only need the strongest blocker; escalate to a fuller run when the client packet needs the complete teardown. Checklist tools and persona proof answer different layers of the same gate.

The handoff failure mode

The person who built the site already knows where Pricing lives, which form field comes first, and that the sticky CTA appears after scroll. The client’s first visitor does not.

That gap shows up as the classic handoff failure: staging looked fine on the builder’s happy path, then the client (or their boss) opens the URL cold and hits a broken primary journey. CI green and “we clicked around” are not the same as proof a stranger can finish the job the page is supposed to do.

Agencies that own go/no-go need a gate that produces forwardable proof, not a Slack message that says “QA’d.”

Layer 1 — checklist / static + primary journey

Ranking launch and client-QA checklists still earn their place. Pieces such as Poszo’s agency website launch QA checklist, BugDrop’s client website QA checklist, Prufa’s client site QA checklist, and AgencyProof’s inspect-before-client-handoff guidance cover the static and procedural layer most delivery leads already recognize:

Walk the primary journey yourself on the frozen staging URL: land → understand offer → reach the conversion action. Mark known exceptions (third-party widget down, content pending legal) so the client packet does not pretend those are surprises.

Layer 1 answers: Is the site intact enough to open? It does not answer: Would different kinds of visitors complete the design intent?

Layer 2 — persona proof on design intent

Behavioral proof fills that second question. Boidwatch flies Census-derived personas through the page in real Chromium sessions—each persona clicks, scrolls, and gets stuck the way a visitor does—then ranks the gaps between your stated design intent and what the flock actually did. The output is a report you can hand over: ranked friction, recommendations, and a public link the client opens without an account.

That is the artifact Layer 1 checklists cannot mint by themselves. Complementary, not competitive: keep Poszo / BugDrop / Prufa / AgencyProof-style lists for static hygiene; add a flock (or capped peek) when the handoff email needs evidence that the primary job works for more than the builder’s path.

Surfaces that fit an agency SOP:

| Depth | How | Use at handoff |

|---|---|---|

| Strongest-blocker gate | Authenticated POST /v1/peek (3 personas, 15 steps, 5-minute hard stop → one finding; full report gated) | Staging freeze; fix or accept before the client URL goes out |

| Quick flock | CLI --quick or MCP boidwatch_quick_check (5 personas) | Faster pass when you want ranked gaps without a full packet |

| Client packet | Full flock (default 20 personas) via CLI or MCP boidwatch_teardown | Shareable report + public link in the handoff note |

The 5- and 20-persona 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. Peek remains force-free capped even on paid accounts: 3 personas, 15 steps, a 5-minute hard stop, and one strongest finding. CLI and MCP create ordinary runs; use the adjacent authenticated POST /v1/peek path for peek.

New accounts get 30 free credits (1 credit = 1 persona) to try the gate. Install and agent docs: llms.txt. Peek details and agent SOP: Agent-native shipping proof.

A repeatable gate (SOP)

Paste this into Notion (or your delivery playbook) and assign an owner.

1. Freeze staging URL + design intent

Lock the URL the client will open. Write one line of design intent (what the page should make a visitor do)—e.g. “Understand pricing and start a trial.”

2. Static / checklist pass

Run your Layer 1 list (links, forms, mobile, analytics, console, metadata). Note known exceptions.

3. Peek or quick flock

Prefer a capped peek when you only need the strongest blocker before the link goes out:

   export BOIDWATCH_API_KEY=fg_live_...
   curl -sS -X POST https://api.boidwatch.com/v1/peek \
     -H "Authorization: Bearer $BOIDWATCH_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"url":"https://STAGING-URL","design_intent":"YOUR ONE-LINE INTENT"}'

Or, for ranked gaps on the documented CLI path:

   boidwatch --json run create \
     --url https://STAGING-URL \
     --design-intent "YOUR ONE-LINE INTENT" \
     --quick --wait

4. Triage blockers

Fix primary-path blockers and re-run. Accept out-of-scope findings in writing. Escalate to a full flock when the engagement needs the complete report packet.

5. Share public report link + known exceptions

Put the public report URL (or the peek’s strongest finding) in the handoff email with a one-paragraph summary and the Layer 1 exceptions list.

What to send the client

Minimum viable handoff packet:

Example tone (adapt; do not invent brand-specific templates):

> Staging is frozen at [URL]. Primary journey: [design intent]. Strongest finding was [X]; we fixed [Y] and accepted [Z] as out of scope for this ship. Full behavioral pass: [public report link]. Static checklist exceptions: [list].

What this gate does not cover

This handoff gate is shipping proof for the primary visitor job. It is not:

Keep those as separate owners and artifacts. Persona proof does not replace them.

FAQ

What should an agency check before handing a website to the client?

Freeze staging, walk the primary journey, complete a static checklist (links, forms, mobile, analytics, console, metadata), then attach behavioral evidence that different visitor types can pursue the design intent—plus known exceptions in writing.

Why isn’t a checklist alone enough at handoff?

Checklists catch intactness and process gaps. They do not show how Census-weighted strangers behave in a real browser against your intent. Builder happy path ≠ first cold open.

How do I produce proof the primary journey works for different kinds of visitors?

Run a Boidwatch persona flock (or capped peek) on the frozen URL with a one-line design intent. Personas drive real Chromium sessions; the report ranks gaps and can include a public link for the client packet.

What artifact should go in the handoff email?

A short summary of the strongest finding and decisions, plus either the public report link (full/quick flock) or the peek finding, alongside your Layer 1 exceptions list—not “looks good.”

Run the gate on the next staging freeze

On the next staging freeze, run a capped peek with the client’s primary job as design intent; put the public report link (or strongest finding) in the handoff email before the client ever opens the site.

curl -sS -X POST https://api.boidwatch.com/v1/peek \
  -H "Authorization: Bearer $BOIDWATCH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://YOUR-STAGING-URL","design_intent":"YOUR ONE-LINE INTENT"}'

Keys: API keys settings · product & example reports: boidwatch.com · agent docs: llms.txt.