Boidwatch ← All posts

Wix / Wix Studio AI QA Before Client Handoff

Wix / Wix Studio AI QA Before Client Handoff

Wix / Wix Studio AI QA usually means official handoff prep plus human launch QA. Those jobs cover ownership, edit access, and launch hygiene. Boidwatch adds visitor proof: Census-derived personas drive real Chromium on the reachable published or shareable Release Manager test-site URL the client will open, then produce a report with a public link—no client account. Set design intent to nav → key page → CTA/form or booking, stopping before the Wix editor / dashboard and before payments. Editor or Studio Preview is not the flock URL. A form confirmation is not proof of inbox or CRM delivery.

What official Wix Studio handoff / Upcode / 10turtle / Wix Monster / Mimiq / Proofday already cover vs visitor proof

An AI-assisted Wix build can look finished while several review jobs remain. Keep their owners and evidence visible.

Official handoff and launch hygiene. Wix Studio’s handoff guide covers collaborator roles, ownership transfer, billing payment requests, and client kits containing tutorials, files, and support notes. Content Mode lets clients update text, links, and media without changing the design. These prepare the client to own and maintain the site.

Wix’s “Will my AI website actually work?” guidance separates a finished-looking demo from a working business site. Its six hygiene checks cover forms, bookings/payments, mobile/speed, indexation, content accuracy, and maintainability. It also distinguishes front-end form confirmation from inbox delivery. Keep those checks with the launch owners; a visitor report does not discharge them.

DFY and agency launch QA. Upcode’s Wix launch-and-QA preflight includes a test matrix, browser/device checks, form and integration verification, metadata, analytics, and handoff notes. It works in the existing Wix account, at a $100/hour development rate with a written estimate.

10turtle describes Wix Studio/Velo QA across devices and breakpoints, plus functional testing of custom features, forms, and integrations. Wix Monster’s Studio service includes pre-launch QA across devices and browsers, followed by training and documentation at handoff. These human services retain their implementation and preflight scopes.

Link paths and generic checks. Mimiq AI’s Wix testing uses simulated visitors on the published URL, not Preview. Visitors follow homepage menus, buttons, and links; reports identify the first stop with screenshots and failed or slow requests. Proofday’s $149 Website Launch Check covers up to 10 public pages on desktop and mobile: links, assets, layout, console, and load timing. It is generic, not Wix-specific, and does not test forms, payments, or logins.

Visitor proof. Boidwatch ranks sampled persona friction against design intent on the client-facing URL. Can visitors find Services, understand the offer, and reach Contact? The report shows attempts and stalls, without guaranteeing conversion. The category framing is AI website QA with real browser sessions.

Published URL or shareable test-site URL — not Editor / Studio Preview

Run the version the client will actually open. Prefer the published live domain or wixsite.com address. For review before a wider release, use a reachable, shareable Release Manager test-site URL—a published test copy, distinct from Preview. Wix documents how to copy and share that test-site URL.

Wix’s Preview documentation explains why Editor or Studio Preview is different: it assigns the Admin role with all permissions, can use sandbox collection data when enabled, and backend events or several APIs may not fire. A successful privileged Preview visit does not establish the public visitor experience.

Check the chosen URL outside your authenticated Wix session. Match content, navigation, and feature state. If approval happens on the test copy, flock that copy. If approval happens after publication, flock the published domain. A report on yesterday’s navigation describes yesterday’s build.

Reachability is the gate. Unpublished sites, password walls, basic auth, bot protection, or unreachable hosts can prevent the reachability check from loading the target. The CLI exits 2 with error.code REACHABILITY_ERROR: the run is not created and no credits are charged. Publish, open access appropriately, adjust an allowlist, or choose a reachable test-site URL before retrying. A password supplied to the client does not establish flock access.

A wall that serves a page can produce a different result. If a run starts but personas never get past entry, the entry-block check exits 9. A failed --assert-* flag can also produce exit 9; JSON stdout contains {results, assertions}. This is a run that started and does not carry exit 2’s no-credit promise. Fix access before treating the result as visitor proof.

The three-layer gate before client handoff

“AI QA passed” is too broad for the client note. Record which layer produced each artifact.

LayerWho owns itEvidence for handoff
1. Official Wix Studio handoff prep + Wix AI-site hygieneDelivery lead and responsible launch ownersClient kit, Content Mode / roles, billing requests, ownership transfer where agreed; six hygiene checks including forms, mobile, and indexation
2. DFY / human launch QA, if usedUpcode preflight or a 10turtle / Wix Monster-class agency passWritten findings and device, browser, functional, or integration checks within the chosen service’s scope
3. Persona peek or --quick flockDelivery lead or agent in the loopNav → key page → CTA/form or booking attempts on the reachable published or test-site URL; public report; stops before editor/dashboard and payments

Run layer 3 after handoff prep and any human launch QA, before the client opens the URL. If an AI revision changed the menu or booking CTA, test while the path is easy to revise. Form confirmation on the page remains separate from inbox or CRM delivery verification.

Choose depth for the decision. A peek caps visits at 3 personas, 15 steps, and a 5-minute hard stop for one strongest finding. --quick runs 5 personas for 5 credits. A full run defaults to 20 personas and 20 credits for the teardown packet. See Agent-native shipping proof and Client-ready UX teardown for agencies.

How to run Boidwatch on a Wix URL (visitor path, not editor / Preview)

Install the CLI and authenticate with an API key. New accounts receive 30 free credits; one credit covers one agent session.

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

# Set BOIDWATCH_API_KEY to your key from:
# https://app.boidwatch.com/settings/api-keys

Use the published or shareable test-site address and name an observable destination:

boidwatch --json run create \
  --url https://WIX-PUBLISHED-OR-TEST-SITE \
  --design-intent "client visitor path: homepage → Services → Contact → submit form and reach confirmation; stop before the Wix editor / dashboard and before payments" \
  --quick --wait

Replace the placeholder with your reachable URL. For a booking journey, use “Find the relevant service from the nav, click Book a call, reach the booking form; stop before the Wix editor / dashboard and before payments.” Check that the form destination is suitable for QA submissions first.

Keep the destination narrow. Reaching a booking state does not prove booking/payment completion. A confirmation does not establish email delivery, CRM routing, or fulfillment. Verify those separately with their owners.

Do not encode Editor or Studio Preview, dashboard login, Content Mode editing, ownership transfer, domain connect, booking payment, or card entry as the intent. This pass evaluates the visitor path. Use --dry-run to preview credit math.

Peek is an adjacent authenticated POST /v1/peek gate with the full report gated; CLI and MCP create ordinary runs. Prefer documented CLI/MCP until peek appears in public llms.txt.

For an agent already in the delivery loop, configure MCP:

claude mcp add boidwatch -- boidwatch mcp

Call boidwatch_quick_check. It returns within about 45 seconds, or supplies a run_id to resume with boidwatch_get_results. Resume that run rather than starting another check. Setup: MCP site QA for Cursor and Claude Code.

What goes in the client note at handoff

Send the public report link, one strongest visitor-path finding, and what you fixed or accepted. The client opens the report without a Boidwatch account.

A usable note, replacing placeholders with actual results: “A persona flock on the published / test-site URL you’ll open found X on homepage → Services → Contact; we fixed Y before handoff. Report: [public link]. Scope: visitor navigation and CTA/form or booking; excludes Wix editor/dashboard, client kits, Content Mode, ownership transfer, domain connect, and booking/payment completion. Form confirmation does not prove inbox or CRM delivery.”

Name the friction. If visitors missed Contact because the menu called it “Start something,” record the navigation change. Do not imply a successful rerun unless you ran it. Put accepted exceptions beside the finding.

Keep raw JSON, credit burn, client-kit contents, and DFY audit rows out of that paragraph. Link their artifacts separately. The broader checklist belongs in Test the site before client handoff; this pass concerns the Wix visitor journey.

Honest comparison posture

Choose by job. Official Wix Studio handoff owns client kits, Content Mode, roles, billing requests, and ownership transfer. Wix’s AI-site guidance covers launch hygiene. Upcode, 10turtle, and Wix Monster retain human launch QA. Mimiq retains published-URL link-path simulated visits; Proofday retains generic page-level checks.

Boidwatch adds Census-derived persona Chromium evidence and a public report on the reachable published or shareable test-site URL. It requires no Wix App Market app and claims no official Wix Partner badge. It does not replace those services or official checks, or provide Velo/Preview debugging, domain connect, or booking/payment completion QA.

The platform parallels are Webflow, Framer, Shopify, WordPress, and Squarespace AI QA. The delivery gate is similar; each build needs its own URL and stopping point.

Before handoff, run a capped peek or documented --quick --wait flock on the URL the client will open. Read the finding, fix or accept it, and put the public report link in the client note.

Product and example reports: boidwatch.com · agent docs: llms.txt · keys: API keys settings.