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
The Before

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.

What I Built

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.

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.

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.

The Result

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
What This Proves

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.