A real-world case study: Claude Fable 5 inside Cursor, with Buddy as the live browser bridge, executed a full business migration — two WordPress sites to one headless Astro storefront, WooCommerce to Shopify, every CRM automation verified against live execution logs before anyone declared victory.
Squeaky Clean Turf is a family-run artificial-turf cleaning company in Phoenix, Arizona, owned and operated by David Schrimpf and Dalis Smith. When this project started they had two WordPress sites (one for services, one for their WooCommerce product line), a GoDaddy hosting bill, a Google Merchant Center account throwing misrepresentation warnings, and a GoHighLevel CRM that only half-knew what the websites were doing.
Over the course of the project, an AI agent — Claude Fable 5 running inside Cursor, with Buddy as the live browser bridge into the tools that have no usable APIs — executed the entire migration:
The result is a faster, cheaper, safer stack — and a checkout, lead, and automation pipeline that was verified working before anyone declared victory, not after. This post documents what was done, what broke, and what an AI agent with a browser bridge changes about the economics of the whole exercise.
The business: a local service company (turf deep-cleaning packages) plus a product company (their own turf cleaner, sold retail and wholesale, including a subscription).
| Layer | Before |
|---|---|
| Service site | WordPress on GoDaddy (squeakycleanturf.com) |
| Product site | Separate WordPress + WooCommerce (squeakycleanturfcleaner.com) |
| Checkout | WooCommerce + aging payment plugins |
| CRM / automations | GoHighLevel, two sub-accounts, wired to WP forms |
| Shopping ads | Google Merchant Center, flagged with errors |
| Analytics | GTM configured for the old WP templates |
The problems, in order of how much they were costing the owners: two domains splitting brand authority and backlinks; WooCommerce maintenance burden (plugins, PHP updates, security patches); Merchant Center misrepresentation warnings; CRM automations that fired for some channels and silently missed others; and a mobile experience that did not match desktop.
Why headless, in one paragraph: the site itself is static HTML served from Cloudflare's edge — there is no origin server to hack, no plugin stack to patch, and nothing to slow down. Anything dynamic (quote forms, newsletter, the Merchant Center feed) runs as small serverless functions. Shopify handles the one thing you genuinely should not build yourself — PCI-compliant checkout — through its Storefront API. The CMS-shaped problems (content, blog, packages) live in version-controlled code, which means every content change is reviewable, diffable, and reversible.
One of the rebuilt pieces the owners love most: the Stink-O-Meter, an interactive estimator that scores smell, pets, and square footage, recommends a package with live pricing, and deep-links into a pre-filled quote form. Package pricing was rebuilt as data, not prose — one source of truth that the estimator, booking widgets, and FAQ all read from.
This is the part most migrations silently get wrong, so it got the most verification. Website quote form, contact form, newsletter, Shopify orders, web chat, Facebook and Instagram DMs, and Google reviews — every channel now lands in GoHighLevel with the right tags, custom fields, and downstream automation, across two sub-accounts.
Honest migration writeups include the failure log. Here's ours — abridged to the instructive ones.
| Problem | Root cause | Fix |
|---|---|---|
| "Trusted on HOMES / GYMS" tiles showed swapped images | Files renamed during an image update, then cached at the CDN | Renamed files to force cache invalidation — cache-busting by filename beats waiting for TTLs |
| Quote notifications going to an old agency address | Legacy workflow recipients | Recipients replaced with the two owners only |
| Website leads not appearing in the sales pipeline | The old GHL form created opportunities; the new site's API path didn't | Added a Create Opportunity step — verified with a live test lead landing in "New Lead" |
| Website leads invisible to the AI sales agent | The AI workflow only triggered on the old GHL form | Added a tag-based trigger so website quote leads also reach the agent |
| Workflow emails couldn't show smell/sqft/package for website leads | Those lived in GHL custom fields the new site never populated | Site now upserts the same custom fields by key — merge tags work identically for both lead sources |
| Phone-call tagging workflow: zero executions in 30 days | No number exists in GHL's phone system — calls ring the owners' real line | Flagged as a business decision (tracking number vs. NAP consistency), not silently "fixed" |
Most of the stack above has APIs. The critical 20% does not. GoHighLevel's workflow builder has no public API for editing triggers, actions, or notification recipients. Merchant Center's diagnostics are a UI-only experience. Shopify's admin onboarding is click-ops.
This is where the workflow got unusual. Fable 5 ran inside Cursor with Buddy as the bridge — a persistent Chrome session the agent could drive: navigate, click, fill, screenshot, and (crucially) read — execution logs, diagnostic panels, saved-state confirmations. Fable 5's adaptive reasoning meant the agent could plan a workflow edit, execute it across a dozen UI steps, and notice when the page state didn't match its expectations — the kind of long-horizon judgment that separates an operator from a script.
That combination changed three things:
1. The no-API wall disappeared. The agent edited GHL workflow recipients, rewrote notification email bodies with merge fields, added pipeline-stage actions, and created tag-based triggers — all through the same UI a human VA would use, but with every step screenshotted and verifiable.
2. Verification became evidence-based, not vibes-based. "The form works" was demonstrated by: submit a live test on the production site → watch the contact appear in GHL with custom fields → watch the workflow execution log show Internal Notification ✓ and Create Opportunity ✓ → see the test lead sitting in the pipeline's New Lead column → delete the test data. Every published workflow with real enrollments — fourteen of them — was checked against its execution logs the same way.
3. The audit loop closed in hours, not weeks. Finding an old agency email address buried in a notification action, or noticing a phone workflow had never fired in 30 days, is exactly the kind of thing that survives years in a normal handover. A bridge-equipped agent walks every workflow, opens every action, and reads every log — because doing so costs minutes.
I have written before about bringing Claude Fable 5 into Buddy's model picker. This project is what that class of model looks like applied to real operations work:
Not if you treat URLs as contracts. Page-level 301s wherever a real equivalent exists; explicit redirects even for pages you're killing; Search Console re-verified before cutover and sitemaps resubmitted immediately after; NAP kept identical to Google Business Profile. Consolidating two related domains usually helps — it concentrates link equity instead of splitting it.
It's the opposite, with one caveat. Static HTML at the edge means fast LCP, no render-blocking plugin soup, and content fully present in the initial response. The caveat: schema, meta, redirects, and feeds don't come from plugins anymore. You own them in code. More work up front, far more control forever after.
The same pass that helps Google's quality systems helps LLM-driven search: LocalBusiness schema with real founders as Person entities, Service schema with real Offer pricing, FAQPage answers that match what's visibly on the page — and removing claims that weren't true anymore. AI systems increasingly cross-reference; inconsistency is the new thin content.
This is the most under-discussed migration risk. Forms are easy to rebuild; the wiring behind them is where businesses silently lose leads. The fix pattern from this project: make the new site populate the same custom fields by key the old forms used, then add tag-based triggers alongside the legacy form triggers — both lead sources flow through identical downstream automation.
| Dimension | Before | After |
|---|---|---|
| Hosting | GoDaddy WP hosting × 2 | Cloudflare Pages (effectively $0 at this scale) |
| Attack surface | WordPress core + plugins × 2 sites | Static HTML + 4 small serverless functions |
| Checkout | WooCommerce plugin chain | Shopify (PCI handled, Shop Pay, native UPS/USPS) |
| Lead capture | WP forms, partially wired | Every channel verified into GHL with logged executions |
| Content changes | WP admin, unversioned | Git — reviewable, diffable, instantly deployed |
| Deploys | FTP-era | ~20 seconds to global edge |
| Shopping ads | Misrepresentation warnings | Clean custom feed with full attributes |
Buddy — the same agent that bridged this migration — audits Google Ads accounts live, verifies conversion tracking in a real browser, researches your market, and hands you a prioritized fix list with real numbers. Free credits to start; bring your own API key if you prefer.
Open Buddy →The interesting part of this migration isn't Astro, or Shopify, or even the SEO mechanics — those are all well-documented individually. The interesting part is that the glue work — the part agencies quote weeks for, the part that always ships half-verified — was done by an AI agent that could write the code and drive the browser and read the logs that prove the system works.
When the agent can see what the customer sees, click what the admin clicks, and read what the auditor reads, "done" stops meaning "deployed" and starts meaning "verified."
— John
