The Build My MVP funnel, end to end.

01 · The offer

One call. 24 hours. A working prototype — before any money moves.

The funnel sells a single, sharp deal: book one call, brief us on your app idea, and within 24 hours a working prototype is in your inbox — free. Payment only enters the conversation after the prospect has seen their own idea running. The full MVP then ships in weeks on a fixed quote, with the client owning the code outright.

Structurally this is a classic risk-reversal offer: the prototype replaces the proposal, the guarantee replaces the pitch, and the call is the only door — there is deliberately no email link, no direct calendar link, no contact form anywhere on the page. Every path leads through the application.

02 · The landing page

Anatomy of the page.

Live at buildmymvp.westfoldinnovations.com. The design system is a high-contrast, direct-response dark theme: near-black ground (#0A0A0A), Archivo 900 headlines with the key phrase underlined in emerald, Hanken Grotesk body, pill CTAs, uppercase tracked-out eyebrows, and cards on hairline borders.

Section by section, top to bottom — each one exists to advance exactly one belief:

• Hero — badge (“Prototype first · pay after”), the headline “Your app, prototyped in 24 hours.”, one CTA, and a trust line naming the deliverable.
• Ticker — a marquee strip restating the promise in fragments (“Prototype in 24 hours ✦ $0 upfront ✦ Book → brief → see it”).
• Proof bar — real shipped product only (chessvia.ai). No invented logos, ever.
• Problem — the founder’s situation: agencies quote months, freelancers vanish, the idea ages.
• The Deal (guarantee card) — the risk-reversal spelled out with the 24h / $0 / 30min callouts, on an emerald-glow card.
• What you actually get — six deliverable cards (UI & UX, frontend + backend, core features only, deployed live, code ownership, a path past the MVP).
• How it works — five steps where the first two are the offer itself: ① book the call ② see it in 24 hours (badged “free”), then scope → build → ship.
• Stats — 24h / $0 / 100% yours.
• Shipped — the Chessvia case study card.
• Who this is for / not for — honest qualification lists that filter bad-fit clicks before they cost a call slot.
• FAQ — leads with “A prototype in 24 hours — really?” and “What does the prototype cost?” (nothing).
• Closing CTA — “The idea is the easy part to keep. The window isn’t.”

03 · A/B variants

Three heroes, statically prerendered.

These aren't headline swaps — each variant is a complete, distinct design system: its own typography, palette, layout language, and signature element, wrapped around the same offer and the same booking funnel. Ads choose the variant by URL, each page is fully static (fast, zero flash), and the variant number follows the visitor into the stored lead and the ad-platform events, so design win-rates are measurable end to end.

• buildmymvp11 — “The Closer”: the flagship dark direct-response system. Near-black, emerald accent, guarantee-led.
• buildmymvp12 — “The $0 Receipt”: warm-paper editorial world, serif display, monospace ledgers — the signature is a literal itemized receipt totaling $0.00 with a “NOTHING DUE UNTIL SEEN” stamp. The money angle, made physical.
• buildmymvp13 — “The Demo Desktop”: a cool-gray workspace where every section is an app window — the hero is a live browser mock of the prototype, and a deck-vs-demo split makes the argument visually. The page performs its own pitch.

The main campaign URL buildmymvp.westfoldinnovations.com serves variant 1 (with buildmymvp10 reserved as a spare alias of the same page). Each variant host carries its variant all the way through the application and into the ad-platform events.

04 · The application funnel

Four steps. The only exit is a booked call.

ad click (utm + click-id) → buildmymvp.westfoldinnovations.com (or the 12/13 variant hosts)
        ↓  every CTA on the page
buildmymvp.westfoldinnovations.com/start
   step 1  what are you building? — project type + the idea, in their words
   step 2  rough budget + timeline (chips, zero typing)
   step 3  name · email · phone (both mandatory) · company  →  lead captured here
   step 4  mandatory booking — Calendly embedded in the page, prefilled
        ↓  fires only on Calendly's real event_scheduled signal
“Your 24-hour clock is set.”  — confirmation with the 3-step what-happens-next

Design decisions that matter: the lead is captured before the booking step, so a prospect who stalls at the calendar is still a lead you can chase. The booking is prefilled with their name and email. The confirmation state only triggers on Calendly’s own event_scheduled message — so the “Schedule” conversion means an actual booked call, not a hopeful click. And there is no skip link, no “or email us instead,” no secondary path anywhere.

05 · Tracking & attribution

Every event, on every platform, deduplicated.

Under the hood: first- and last-touch UTMs and click IDs (fbclid, gclid, rdt_cid) are captured on landing and stored with the lead; Meta’s _fbc cookie is synthesized even when the pixel is blocked; the server-side Conversions API calls carry hashed email/phone/name plus IP and user-agent for match quality; and the same event ID travels through the browser pixel, the server event, and Google’s transaction_id so nothing double-counts. All of it is env-gated — the moment the pixel keys are added, every channel lights up.

06 · Lead data & operations

Where the filled-out information lives.

• Storage — every brief becomes a lead row (name, mandatory email, mandatory phone, company, project type, the idea, budget, timeline, variant, full attribution, IP/UA, timestamps) in Postgres (auto-creating schema; JSONL + structured logs as the no-keys fallback).
• Notifications — each lead can email the team (Resend), post to Slack, and forward to any webhook/CRM.
• Dashboard — /admin (basic-auth) shows every lead with per-offer and per-source breakdowns, plus a one-click Excel-safe CSV export.
• The booking itself — lives in Calendly, prefilled from the form.

07 · Automated follow-up

Email and SMS, from booking to prototype.

The form captures a mandatory email and mandatory phone number on every lead, so the follow-up machine always has both channels — and the appointment carries itself to the call without anyone chasing:

Every message is tied to the lead record, so the brief, the attribution, the booking, and the full follow-up history live on one timeline per prospect.

08 · The ad campaigns

Three channels, scripted, validated, created paused.

Meta (priority 1). One script call creates: campaign WF | buildmymvp | Meta | Leads → two ad sets (Advantage+ broad, and a founder-interest stack resolved live against Meta’s API) → three ads each, with ad #3 automatically pointed at the buildmymvp12 variant host so copy testing starts on day one. Everything arrives paused, optimizing on the pixel Lead event. Sample creative:

Google (priority 2). Generated Ads Editor CSVs — importable without a developer token — with two ad groups (mvp development: 8 commercial keywords; build my app idea: 6 intent keywords, each in phrase + exact), a 17-term negative list (jobs, courses, free-seekers…), and a 12-headline responsive search ad (“App Prototype in 24 Hours”, “See Your MVP Before You Pay”, “Prototype First, Pay After”…), all within character limits, verified by an automated validator.

Reddit (priority 3). Campaign script targeting r/startups, r/Entrepreneur, r/SaaS, r/sideproject, r/smallbusiness with plain-spoken promoted posts (“Agencies send proposals. We send a working prototype within 24 hours. $0 upfront.”).

Every URL in every channel carries the same convention — utm_campaign=wf_buildmymvp_{channel}_leads, utm_content={adset}_{ad} — so the admin dashboard and the platform reports reconcile line for line. The creation scripts refuse to run if the landing domain isn’t live, and every object is created paused: nothing can spend by accident.

09 · Quality & testing

Audited three times. Driven end to end in a real browser.

The system behind this funnel went through three adversarial audit rounds (~95 findings found and fixed — from a dead Meta API version to CSV-injection hardening to silent tracking double-counts). The buildmymvp funnel specifically was then driven end-to-end in a real browser: an ad-style URL with click IDs → variant landing → attribution captured → all form steps → the stored lead verified to contain the variant, the exact ad, and every click ID → the embedded booking → the Schedule conversion firing on the real booking signal. Accessibility scans return zero violations on the application page.