Developer Marketing Case Study · Free WHY Funnel V3

The Funnel That Lives
Inside the Product

Most funnels get bolted onto the side of a business as another landing-page stack. I built this one as a route group inside the production Next.js app, behind a feature flag, with its own database migrations, a CI gate on every deploy, and a written spec the engineering team could execute against.

0
Deploys needed for copy changes: blocks live in the database
404
What every funnel route returns until the feature flag flips on
v4.2
Result-page design iterations, each scored against a written audit

Every new funnel meant a new surface, a new identity, and data stitched together later.

The standard playbook for a new acquisition funnel is a separate landing-page stack: a page builder, its own forms, its own contact records, and a pile of integrations to reconcile who did what. Every version of that playbook pays the same tax. The person who signs up on the landing page and the person who logs into the product are the same human, but the systems treat them as two.

The WHY Institute already had a production app with a real database and real identity: the WHY.os companion at live.whyinstitute.com, built on Next.js 16 and Supabase. (That app has its own story, covered in the Live Your WHY.os case study.) For the third version of the Free WHY funnel, I made the architectural call that shaped everything else: build the funnel where the product lives. A shared database and shared identity beat a separate surface, every time.

The catch is that building inside a production app means production standards. A half-finished funnel cannot leak into a live product. So this became a real engineering project, run by a marketer.

Shipped dark, fail closed, and editable without a deploy.

The funnel lives at a /discover route group inside the production codebase, and it shipped dark from day one. Nothing about it is visible or reachable until it is switched on:

  1. 01
    Ship Dark
    Every funnel route returns a 404 unless FUNNEL_V3_ENABLED=1 is set in the environment. Ingest endpoints fail closed: without a signed secret, they reject the request. Production stays clean while the funnel is built, tested, and reviewed inside it.
  2. 02
    Data & Identity
    Supabase migrations define the funnel's schema alongside the product's. Visitors get durable guest records through a cookie capability, and a full account is created at purchase-return, so one identity runs from first click to paying customer with nothing to stitch together later.
  3. 03
    Copy Without Deploys
    Funnel copy lives in database-stored blocks, editable by a teammate at /admin. Headline tests and message changes happen without touching code, without a deploy, and without waiting on me.
  4. 04
    Engineering Discipline
    CI runs type-checking and a full build before Render is allowed to auto-deploy. Staging and production differ by environment variables only, so what was tested is what ships. The full funnel flow was verified end to end on the dev environment.
A map of the Free WHY funnel in three rows: getting a WHY, seeing it and the $97 offer, and into the app. Each step is a card with a score out of 10 and a works, polish, or broken label
The whole funnel on one page, from my August 19 walkthrough: every step scored out of 10 as a first-time visitor would experience it, with steps owned by the tech team marked separately.

The funnel also depends on systems owned by the tech team: the checkout URL, Stripe metadata, and post-purchase callbacks. Instead of a Slack thread of requests, I wrote the dependency contract as a spec document engineers could execute against, with the exact fields, formats, and handoff points defined. Marketers who can write specs stop being a source of ambiguity for engineering.

The craft work got the same rigor as the plumbing. The result page went through versioned mockups from v1 to v4.2, each round scored against a written design audit that climbed from 6.5 out of 10 to roughly 9. That included a spacing audit that measured actual pixel voids, stakeholder feedback rounds, and an ethical persuasion review: no fake urgency, no strikethrough pricing games. Nine fully authored result pages are planned, one per WHY archetype, with four dynamic personalization mechanisms.

The v4.2 result page for the Contribute WHY: “Your WHY is CONTRIBUTE” on navy with a yellow highlight, a one-in-five stat, a call to action, and a warm photo of two people picking up spilled oranges
The v4.2 result page for Contribute, one of the nine WHYs. The call to action changes with the life area the visitor picked in the opening questions (here, career).
A “People with your WHY often say…” section with four statements, each with That’s me, Sometimes, and Not really buttons
“Sound familiar?” asks the visitor to react, not just read. Each answer is a signal the page can use later.
An “Understanding where you’re at” section showing Your WHY as discovered and Your HOW and Your WHAT as locked layers
The upgrade case, told honestly: the WHY is one of three layers, and the other two are shown as locked rather than faked.
The admin funnel dashboard showing weekly funnel steps by traffic source, above a library of editable copy blocks
The /admin side: funnel steps by source, and below them the copy blocks the funnel pages read at render time. A teammate edits these, and nothing is deployed.

Persuasion that needs a fake countdown timer is persuasion that did not do its research. Every conversion mechanism on this funnel survives an honesty audit.

A funnel in the production codebase, verified end to end, waiting on a flag.

The funnel is built, merged into the production app's world, and verified. Launch is a configuration change, and everything risky was de-risked before anyone could see it.

  • Funnel routes live inside the production Next.js 16 + Supabase codebase, shipped dark behind FUNNEL_V3_ENABLED
  • Ingest endpoints fail closed without a signed secret, so no unauthenticated data can enter the system
  • One continuous identity: guest records via cookie capability, account creation at purchase-return
  • A teammate edits funnel copy at /admin with zero deploys and zero engineering involvement
  • CI (type-check + build) gates every Render auto-deploy; staging and prod split by env vars only; full E2E verified on dev
  • The tech-team dependency contract (checkout URL, Stripe metadata, callbacks) shipped as an executable spec
  • Result page hardened through v1 to v4.2 with scored audits, from 6.5/10 to roughly 9, plus an ethical persuasion review
The /discover landing page: “Discover your WHY — free” with a single Start button
The front door: one promise, one button.
The first qualifying question: how much do you already know about WHY, with three answer buttons
Two qualifying questions shape everything after the result.
The $97 offer page: “Your WHY is the start. Your WHY.os is the full picture,” with a WHY, HOW, WHAT diagram
The WHY.os offer gets its full shot before the free account is offered.
Inside the app after onboarding: the Life Wheel with seven life areas and a focus area picker
Into the product: the same identity lands in the app, with nothing to stitch together later.

Screens from the August 19 end-to-end walkthrough.

The most valuable funnel skill in 2026 is knowing where the funnel should live.

Any marketer can assemble landing pages. This project required deciding that the funnel belonged inside the product, then earning the right to build there: feature flags, migrations, fail-closed endpoints, CI gates, and a spec engineers could act on without a meeting. Conversion craft and production engineering came from the same person, which is exactly why the handoff seams that kill most funnel projects never appeared.

When the funnel shares the product's database and identity, acquisition stops being a separate system you reconcile later and becomes a feature of the product itself.