Framer AI QA Before Client Sign-Off
Framer AI QA Before Client Sign-Off
Framer AI QA usually means canvas/layer scans (Framer QA plugin, Preflight Live Audit), Framer Agents review on a branch, or a launch checklist (a11y/SEO/links/forms). Those jobs catch hygiene inside the editor; they do not run Census-derived personas through the journey the client will open. Boidwatch does the visitor-proof job: a capped peek or --quick flock in real Chromium against the Framer preview or published URL with the page’s conversion as design intent, then a shareable report with a public link—no client account. Use it after canvas QA and the launch checklist and before “Approve,” especially when Framer Agents or a designer just shipped a major page.
What Framer Agents, QA plugins, and Preflight already cover vs visitor proof
Framer delivery leads keep getting pitched “AI QA” as one product. On a Framer project it is several jobs that look similar in a sales deck and fail differently on the day the client opens the URL.
Canvas and layer QA. The Framer QA plugin and Framer Preflight (canvas scans plus Live Audit) inspect the file inside the editor: broken layers, structure, hygiene the canvas can see. The output stays in the project. It never opens the URL the client will click.
Editor-side Agents. Framer Agents review work on agent branches. Agency workflows in the Pixlform style add a human senior pass on top of that in-Framer review. The artifact is a reviewed branch, not a cold open by a stranger.
Launch checklists. Framer’s launch skill, and agency lists in the getproofday style, cover publish hygiene: accessibility checks, SEO, links, and forms. That is a checklist. It is not an accessibility certification, and it does not fly personas through the conversion.
Visitor proof. Boidwatch is platform-agnostic: a reachable URL in, a flock of Census-derived personas in real headless Chromium, a public report out. It is not a Framer Marketplace plugin, and it is not a Framer Partner badge. Design intent is the conversion the client hired you to ship—pricing to Book a call, homepage to Contact, a CMS post to the newsletter form.
Canvas scans prove the layers are intact. Checklists prove the launch items were ticked. Personas prove strangers can finish the job on the URL the client will open. Keep the owners separate in the SOW. The same split, on a Webflow stack, is Webflow AI QA before client sign-off. The generic gate is Test the site before client handoff; the category cut is AI website QA with real browser sessions.
Preview branch URL vs published domain
Flock the URL the client will open. Match auth, seed data, and feature state to that URL. A pass on a different host is a different site.
Sign-off on a preview. If Approve is on a Framer staging or collaborate preview—including an agent-branch preview—run the flock on that preview. Publishing later, or a green pass on yesterday’s custom domain, does not prove today’s branch.
Sign-off on the published domain. If the client approves only after you publish to the custom domain, flock that published URL. Do not substitute the canvas preview and call it the same proof.
Reachability. When the target cannot be reached, or serves a bot-protection challenge, the CLI exits 2 with error.code REACHABILITY_ERROR. The run is not created and no credits are charged. error.message says why and how to fix it. Open the preview for the flock, or point at a reachable URL that matches what the client will see, then re-run.
A page that loads but stops every persona at the door is a different result. Exit 9 is the always-on entry-block check (or a failed --assert-* flag): the personas never got past the entry URL. With --json, stdout is {results, assertions}. A password wall that still serves a page lands here when the flock loads the URL and never gets past it—not on exit 2, because the host responded. Fix access before you treat the run as visitor proof. Exit 2 is reachability. Exit 9 is a check on a run that started. Neither result means the client will Approve, and neither result means the publish will be clean.
Preview the credit math first with --dry-run if you want the cost before the flock flies.
The three-layer gate before client Approve
Run the layers in order. Do not collapse them into one “AI QA passed” line.
| Layer | Who owns it | What it proves |
|---|---|---|
| 1. Canvas scan | Framer QA plugin or Preflight Live Audit | Broken layers and hygiene inside the editor |
| 2. Launch checklist | Framer launch skill or your agency list | Accessibility, SEO, links, and forms—as a checklist, not a certification |
3. Persona peek or --quick flock | Delivery lead or the agent in the loop | Strangers can attempt the primary conversion on the Framer preview or published URL; public report link for the client note |
Layer 3 sets design intent to the primary conversion. It sits after canvas QA and the launch checklist, and before Approve. If Framer Agents or a designer just shipped a major page, run the capped pass the same day—do not wait until the night before the call.
Depth scales with the note you have to send. A peek (3 personas, 15 steps, 5-minute hard stop) is the strongest blocker before the call. --quick is a small flock when the note needs ranked gaps. The full flock is the teardown packet. The peek gate itself is Agent-native shipping proof. The billable packet is Client-ready UX teardown for agencies.
How to run Boidwatch on a Framer URL
Boidwatch needs a reachable Framer URL: the staging or collaborate preview, or the published domain. No Marketplace install and no canvas embed. Authenticate with an API key and point the run at that URL.
Install and auth (new accounts: 30 free credits; 1 credit = 1 persona; no card for that pool):
curl -fsSL https://boidwatch.com/install.sh | sh
# or: brew install boidwatch/tap/boidwatch
export BOIDWATCH_API_KEY=fg_live_...
# key from https://app.boidwatch.com/settings/api-keys
CLI — Framer preview or published domain, client path as design intent:
boidwatch --json run create \
--url https://FRAMER-PREVIEW-OR-DOMAIN \
--design-intent "client path: homepage → pricing → Book a call" \
--quick --wait
--quick runs 5 personas for 5 credits. Swap the design intent for the journey you actually shipped:
| Framer build | Example design intent |
|---|---|
| Pricing with a call form | “Open pricing, click Book a call, complete the form” |
| Services site | “Land homepage → Services → Contact” |
| Framer CMS blog | “Framer CMS blog → newsletter signup” |
Drop --quick for the full client packet (default 20 personas, 20 credits). Use that only when the note needs the teardown, not as the default before every Approve call.
Cap choice
| Depth | Cost shape | Use before Approve |
|---|---|---|
| Peek | 3 personas, 15 steps, 5-minute hard stop → one strongest finding | Strongest blocker before the call |
--quick | 5 personas, 5 credits | Small flock when the client note needs ranked gaps |
| Full flock | 20 personas, 20 credits | Teardown packet only |
Peek is an adjacent shipping gate: authenticated POST /v1/peek on https://api.boidwatch.com. The full report stays gated. Prefer the documented CLI and MCP until peek appears in public llms.txt. CLI and MCP create ordinary runs, not peeks.
MCP (CLI v1.1.0 or later), when the agent is already in the delivery loop:
claude mcp add boidwatch -- boidwatch mcp
Call boidwatch_quick_check. It returns within about 45 seconds, or a run_id you resume with boidwatch_get_results—do not call quick_check again for the same run. Use boidwatch_teardown only for the thorough client packet. Wiring: MCP site QA for Cursor and Claude Code and Agent-native shipping proof.
What goes in the client note at sign-off
The client-facing artifact is a public report link. No Boidwatch account, no invite, no second login. Copy the link into the Approve note with one line: the strongest friction finding.
Narrate it as visitor proof on their URL: “A persona flock on the Framer URL you’ll open found X; we fixed Y before Approve.” Name the finding and the fix or the accepted exception. Do not promise that Approve will go through, and do not promise the publish will be clean.
Keep the tool jobs in separate sentences. Do not paste raw JSON, credit burn, or canvas-plugin screenshots into the same paragraph as the flock proof. Canvas hygiene and visitor proof are different evidence. The handoff shape is Test the site before client handoff. The Webflow parallel for keeping review tools and the flock apart is Webflow AI QA before client sign-off.
What the report carries, enough for a cold open:
- The design intent you set on the run
- A Census-derived persona flock (sampled from 36,000+ profiles) driving real Chromium
- Ranked gaps against that intent, with recommendations
- Funnel and friction framing a stakeholder can skim
Honest comparison posture
Choose by job. Boidwatch does not replace Framer QA, Preflight, or Framer Agents.
| Tool | Job it owns on Framer projects | Shape |
|---|---|---|
| Framer QA plugin / Preflight | Canvas hygiene | Canvas scans and Live Audit inside the editor |
| Launch checklists | Publish checklist | Framer launch skill and getproofday-style lists: accessibility, SEO, links, forms. Not a certification |
| Framer Agents / Pixlform-style review | In-Framer agent review plus a human senior pass | Agent branches and a senior review workflow |
| Boidwatch | Pre-sign-off persona Chromium flock on the Framer preview or published URL | Public report link as the client-ready proof artifact. Not a Marketplace plugin |
This is the same delivery-gate job as Webflow AI QA, on the Framer stack. Canvas tools and launch checklists keep their jobs. The flock covers the visitor-proof gap those tools do not run. Pair them.
FAQ
How should a Framer agency QA a site with AI before the client approves?
Finish the canvas scan (Framer QA plugin or Preflight Live Audit) and the launch checklist (accessibility, SEO, links, forms). Then run a persona peek or a --quick flock on the Framer preview or published URL the client will open, with the primary conversion as design intent. Put the strongest finding and the public report link in the client note. A green canvas audit is not visitor proof.
What’s the difference between Framer canvas / Preflight QA and a persona visitor proof pass?
Canvas and Preflight QA inspect layers inside the editor. A persona visitor proof pass flies Census-derived personas through real Chromium on the client-facing URL and ranks friction against design intent. Different evidence, different owners. Boidwatch does the second job. It does not replace the Framer QA plugin or Preflight.
Should I run Boidwatch on a Framer branch preview URL or the published domain?
Run it on the URL the client will open. If sign-off is on a staging or collaborate preview, including an agent branch, flock that preview. If sign-off is on the live custom domain after publish, flock that domain. Match auth, seed data, and feature state. If the URL cannot be reached or serves a bot-protection challenge, the CLI exits 2 (REACHABILITY_ERROR) and charges no credits. If the page loads but no persona gets past the entry, the CLI exits 9 (entry-block).
What should go in the client note at Framer sign-off?
The public report link, one line for the strongest friction finding, and what you fixed or accepted before Approve. A usable sentence: “A persona flock on the Framer URL you’ll open found X; we fixed Y before Approve.” Keep canvas-plugin screenshots, raw JSON, and credit burn out of that paragraph.
Paste the Framer URL into a peek before Approve
Before the client Approve call, paste the Framer preview or published URL into a capped peek with the page’s primary conversion as design intent. Drop the strongest finding and the public report link into the client note. Until peek is in your loop, the documented flock is --quick:
boidwatch --json run create \
--url https://FRAMER-PREVIEW-OR-DOMAIN \
--design-intent "client path: homepage → pricing → Book a call" \
--quick --wait
Product and example reports: boidwatch.com · agent docs: llms.txt · web app: app.boidwatch.com · keys: API keys settings.