The Website + Growth-Plan Play

This is the productized version of what we ran in a single morning for Edge of the Lake: diagnose a local business's website, hand them a strategy document they can't argue with, show them a working custom demo of their own rebuilt site on a live subdomain, and close a build. It works because you show up with the finished thing, not a proposal.

Stage 1 Target & qualify

The play only works on the right prospect. Look for a business that already has money moving through a website that's failing to move it well.

Ideal fit — all four

• A real, experiential asset — a place, a product, an experience worth photographing (winery, restaurant, venue, med-spa, boutique hotel, gym, tour operator).
• An existing site that under-converts — pretty story, no path to buy/book; prices hidden; no reserve button; stale content.
• A commerce or booking need — reservations, memberships/club, events, products, deposits. Something with a transaction.
• Owner-operated — the decision-maker is reachable and cares. (A neighbor, a referral, a regular.)

Walk away if

• Purely informational, nothing to sell → no conversion story, no ROI hook.
• Owner loves the current site, or a committee decides.
• No budget and no revenue for the plan to unlock.

Stage 2 Recon — their site and their stack

Do this before the conversation. You want to walk in already knowing what's broken and what it runs on.

2a · Walk the site as the customer

Open the live site and move through it as each buyer type. Find where the money-path breaks. Capture a page → works → wall the guest hits table — it's the spine of the strategy doc.

2b · Fingerprint the platform

Know what they run before you pitch — it decides your "reuse vs. replace" story. Reusable commands:

# Host, CMS, and CDN from headers + HTML
D=https://THEIRDOMAIN.com
curl -sI $D/ | grep -iE "server:|x-powered-by:|x-pingback:|cf-ray:|link:"
H=$(curl -s $D/)
echo "$H" | grep -o 'name="generator" content="[^"]*"'      # WordPress/Drupal/etc + version
echo "wp-content:  $(echo "$H" | grep -oc 'wp-content')"      # WordPress
echo "$H" | grep -o 'wp-content/themes/[^/"'"'"' ]*' | sort -u  # theme
echo "$H" | grep -oiE 'commerce7|c7t-|shopify|squarespace|wix|parastorage|bigcommerce' | sort | uniq -c

Interpreting it decides your pitch:

Deliverable: a one-page "here's exactly what you run" table (see EOTL Appendix G). It proves you did the homework and disarms the "are you going to throw away everything I paid for?" fear.

Stage 3 The strategy artifact — SWOT + 30/60/90

This is the document that makes you look like a strategist, not a web guy. It's long, rigorous, and mostly reusable structure — you swap the facts per client.

The reusable outline

1. Evidence standard — tag every claim [V] verified / [A] assumption / [H] hypothesis. Protects credibility; lets the owner see known vs. inferred.
2. Context & stakes — their market position, the 4–5 load-bearing assumptions, and the "no-change 90-day trajectory" table.
3. SWOT — each item with: why customers value it, reproducibility, how to monetize, and one immediate action.
4. TOWS + scored strategy portfolio — SO/ST/WO/WT intersections, ranked by impact × speed × cost × confidence.
5. Revenue engines — one teardown per money-maker (the gap, the move, the metric that matters).
6. Top-5 next-30-days — owner / effort / cost / deadline / success metric / stop-or-pivot criterion.
7. 90-day experiment portfolio — each with budget, success line, failure line, and next move either way.
8. Weekly scorecard — ~10 revenue metrics with triggers. Exclude vanity (followers, impressions).
9. Info needed from ownership — the handful of numbers that sharpen the plan.
10. Final recommendation + executive summary.

How to build it fast (the AI loop)

• Feed the model only verified facts (site content, public data). Never let it invent prices, awards, or numbers.
• Generate the structure, then verify every factual claim against the live site before it ships. Tighten tags to what's actually live.
• National/industry benchmark data (volume trends, top- vs bottom-quartile behavior, club churn, DTC mix) is the credibility layer — cite it, keep it current.

Stage 4 The demo build — a custom site of their own

The demo is the close. Nobody argues with a working version of their own rebuilt site. Build it to feel real, on a real URL.

4a · Brand from the subject's own world

• Palette — 5–6 named colors derived from real things in their world, each with a hex. (EOTL: lake-water, caliche, Tempranillo, prairie grass, clapboard.) Avoid the AI defaults: cream + terracotta; near-black + acid accent; broadsheet hairlines.
• Type — a display face with a point of view, a quiet body face, and a mono utility face for prices/labels. Not the category's default pairing (no Playfair-on-a-winery).
• One signature element — a single memorable device drawn from their world (EOTL: "the Waterline" horizon motif). Everything else stays quiet. Then remove one accessory.

4b · Two-pass method

1. Plan — a compact token system (colors, type, layout concept, signature) + ASCII wireframes for the key pages. Show it before building.
2. Self-critique — ask honestly: "would I have produced this for any business in this category?" Wherever the answer is yes, revise and say what changed.
3. Build — derive every color/type decision from the tokens. Reuse one shared token/CSS block across all pages.

4c · Page set & what to make real

Discipline that keeps it honest

• Real copy, always — warm, plain, active voice; a button says exactly what it does and the confirmation reuses the word ("Join Edge" → "Joined"). No lorem, no "nestled/curated."
• [CONFIRM: …] tokens, never invented facts — prices, hours, drive times, awards you don't have get a dashed placeholder, not a guess. Set them later from the real source.
• Publish every price. The mono utility face makes that honesty visible.
• Expiring-content module — the banner takes a data-expires date and hides itself. Demoes the "content can't rot" fix and becomes their self-service pattern.

Stage 5 Deploy to a live subdomain

Cloudflare Pages + a subdomain of your own domain. Live in minutes, free, no server. This is what turns a mockup into "go look at it right now."

5a · Ship it

# Stage a demo-site/ folder: index.html + one file per route + a styled 404.html
# Pages serves /experiences from experiences.html automatically (clean URLs)
npx wrangler@latest pages project create CLIENT-demo --production-branch main
npx wrangler@latest pages deploy demo-site --project-name CLIENT-demo --branch main --commit-dirty=true
# -> live at https://CLIENT-demo.pages.dev immediately

5b · Put it on YOURDOMAIN subdomain

# 1) register the custom domain on the Pages project (needs pages:write)
API=https://api.cloudflare.com/client/v4
curl -s -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  "$API/accounts/$ACCT/pages/projects/CLIENT-demo/domains" \
  --data '{"name":"demo-client.yourdomain.com"}'
# 2) create the CNAME -> needs a Zone:DNS:Edit token (NOT the account id!)
curl -s -X POST -H "Authorization: Bearer $DNS_TOKEN" -H "Content-Type: application/json" \
  "$API/zones/$ZONE/dns_records" \
  --data '{"type":"CNAME","name":"demo-client","content":"CLIENT-demo.pages.dev","proxied":true}'
# cert auto-provisions in ~1-2 min; verify: curl -sI https://demo-client.yourdomain.com/

5c · Non-negotiable demo hygiene

• noindex + a "Concept demo — not the official site" banner on every page. Keeps it out of Google and out of confusion with the real business.
• A styled 404 for routes you haven't built ("this page comes in the full build").
• Optimize hero images — sips -Z 1500 -s formatOptions 55 in.jpg --out out.jpg (664KB → ~290KB). Rural-mobile FCP matters.
• Use the client's own photos (their property, their pitch) — fine for a demo; note high-res originals for production.

Stage 6 The go-forward platform

The demo is hand-coded and static — great to show, but the owner can't edit it. The production recommendation must give them a custom look and self-service editing and their commerce engine. The principle: keep the engine, replace the wrapper.

For "they maintain it without me," Webflow wins — it's built for agency-to-client handoff. The commerce engine (Commerce7/Shopify/etc.) embeds via its own widgets on any platform, so nothing about members, inventory, or checkout moves.

Stage 7 Price & timeline

Because the design, copy, and IA are already done in the demo — 30–40% of a normal project — you're pricing a focused build, not a from-scratch one.

Recurring (owner pays — usually a wash)

Webflow ~$23–39/mo · commerce engine unchanged · domain unchanged · their old host removed. Net ≈ what they pay today.

Timeline — be honest: labor vs. calendar

• Focused labor ≈ 2 weeks (~60–100 hrs). The pages aren't the bottleneck — the commerce integration is the one real variable (styling their engine's widgets, testing flows without breaking the live store).
• Calendar 2–4 weeks — padded by client latency (access, photos, answers, approvals), not typing. Don't quote 4–6 unless the client is slow; you'll under-sell your speed.

Stage 8 The close

8a · The meeting punch list

• Open with the wedge sentence + the one-line diagnosis.
• Show, in order: homepage → the money pages (club, events, shop) → the strategy doc.
• Get decisions: green-light the rebuild? the one strategic call (usually: stop the margin-killing discounting?); scope; a launch date tied to their busy season.
• Collect: the [CONFIRM] answers, real prices, photos, engine admin + DNS access, and the 5 sharpening numbers.
• Make the offer: recommended tier + ~2–4 weeks + recurring-is-a-wash.
• Name the clock: a real seasonal deadline (a festival, trail, holiday season) makes it now-not-later.
• Close: agreement + deposit → access → content → kickoff date.

8b · The upsell questionnaire

Most owners under-sell the highest-margin things they already own. Ask, and you surface the scope:

• What can a customer not book or buy online today that they should be able to?
• Do you have a club / membership / loyalty? Is the price published? Can they join online?
• What private rooms / experiences / events do you offer — and are they bookable, or phone-only?
• Gift cards? Private buyouts on your closed days? Seasonal packages?
• What do you turn away or do manually that a form could capture 24/7?
• Where does your best traffic come from that you're not capturing a contact from?

Appendix A · Reusable assets to clone

Appendix B · Landmine registry

• Never invent facts — prices, awards, hours, drive times. [CONFIRM] tokens, then pull from the real source (their menu/site).
• Verify the platform before you pitch — the reuse-vs-replace story hinges on it.
• Python, not perl, for HTML injection (UTF-8 double-encoding).
• Edge-cache lag after deploy — cache-buster query / hard refresh; check the .pages.dev origin.
• Account id ≠ API token (32 hex vs. ~40 mixed-case, shown once).
• Owner-facing tone — critique the situation, not the person; reframe to unrealized revenue.
• Quote calendar honestly — separate labor from client-latency; the commerce integration is the real variable.
• Correct your own guesses — when the authoritative source (their real menu) contradicts a demo assumption, fix it and say so (EOTL: two appellations were wrong until I pulled the menu).

Appendix C · Worked example — Edge of the Lake

Everything above, run start-to-finish in one morning, for a family lakefront winery. Deliverables produced:

• Live-site analysis + platform fingerprint (WordPress 7 / WP Engine / Cloudflare / Commerce7 — the reuse target).
• Owner-facing SWOT + 30/60/90 strategy doc, with platform plan (Appendix G) and investment/timeline (Appendix H).
• A full custom demo site — home (aerial hero), Visit (reservation), Wines (real prices, cart → checkout), Experiences, Private events, Wine club (online join) — on a Cloudflare subdomain.
• Meeting punch list + upsell questionnaire.

The proof isn't the deck. It's that they can click their own new website before they've paid you a dollar.