getwalka

Static marketing site (no framework, no build step) deployed on Vercel. Each page is a self-contained .html file with its own inline <style>; routing is just file-based plus the /invite/:path* rewrite in vercel.json. PostHog is wired into every page for analytics.

Postpartum Mums test flow (/moms)

A standalone, flagged-off onboarding + checkout experiment living alongside the main site, built to test whether postpartum/pregnant mums will sign up and commit under a gentler commitment mechanic. It does not touch the main flow or its stake logic (it does link to the shared /terms and /privacy pages).

Cohort only. Solo is out of scope for this flow, it's hidden behind a separate feature flag on mobile, not built here. Every /moms signup joins a cohort group.

As of 2026-10-31, /moms is a two-screen flow: home (a full marketing- style landing page, no quiz) then checkout. This replaces the earlier 13-screen onboarding quiz (motherhood stage, motivations, barriers, interludes, connection, conversations, baseline, clearance, contact, preparing, results) entirely, the same landing+checkout shape the November-challenge funnel (couch6k.html/couch6k-copy.js/ couch6k-app.js) already moved to. Matching/personalization questions ("which stage are you") are gone from this page; that happens in the app after signup instead, same as couch6k moved coach selection post-purchase. STEP_IDS in moms-app.js is now just ["home", "checkout"]; COPY.landing, COPY.cohort, and RESULTS_COPY (the old quiz's personalization data) were deleted along with the quiz, and moms_landing_view no longer fires (see moms_home_viewed below instead).

Files:

• moms.html: the route itself (page shell, styles, landing + checkout markup containers). Styled to match myplan.html (same Anton/Inter fonts, same lavender/cream/pink/mint palette, same button/spacing system) rather than this funnel's older sage/Quicksand look, which moms-success.html still uses.
• moms-copy.js: every piece of copy and every tunable config value (feature flag key, Stripe link/mode, plan price/billing interval). Edit this file, not the others, to change wording or pricing.
• moms-app.js: the step engine (state machine, resume, analytics, Supabase sync, Stripe handoff). Shouldn't contain user-facing strings.
• moms-success.html: where Stripe redirects after a successful payment.
• supabase/moms_leads.sql: schema + RLS policy for the leads table (run once in the Supabase SQL editor). The quiz-answer columns (motherhood stage, motivations, barriers, etc.) stay in the schema, nullable and simply no longer written to.

Enabling / disabling the flow

Gated by a PostHog feature flag (PostHog is already on every page):

1. In the PostHog dashboard, create a feature flag with the key moms-postpartum-flow (see FEATURE_FLAG_KEY in moms-copy.js) and release it to whoever should see the test.
2. If PostHog can't be reached (blocked, slow), the page fails closed: visitors see a plain "not open yet" message, never a broken flow.
3. To share a test link before the flag is rolled out, open /moms?preview=1 once in a browser. That unlocks the flow on that device via localStorage, regardless of the flag. /moms?preview=0 removes the override.

Geo gate: US/Canada only

/moms is additionally restricted to US and Canadian visitors (GEO_ALLOWED_COUNTRIES in moms-copy.js), independent of the feature flag above.

• middleware.js (Vercel Edge Middleware, matches /moms only) reads Vercel's own x-vercel-ip-country request header and stamps it onto a walka_geo_country cookie. This is the one piece of this experiment that isn't purely static: everything else here is plain files with no build step, this is a small edge function. No npm dependency, no @vercel/edge package; it hand-writes the x-middleware-next: 1 response header that tells Vercel to keep serving the static route rather than replacing the response.
• moms-app.js reads that cookie and, if the country isn't in the allowed list, shows COPY.geoGate instead of the wizard. The decision lives here, not in middleware, so there's one place (same as the feature-flag gate) that owns who gets in.
• Fails OPEN, the opposite of the feature-flag gate: if the cookie is missing or empty (middleware didn't run, e.g. plain vercel dev or a local file open), the visitor is let through rather than blocked. A detection hiccup should never cost a real US/CA signup.
• ?preview=1 bypasses this gate too, same as the feature flag, so QA can test from any location.
• Every visitor's country, allowed, blocked, or unknown, is written to moms_leads.country (upserted on landing, before onboarding even starts) and sent as a moms_geo_blocked PostHog event when someone is actually blocked, so the country breakdown is visible in both places, not just the pass/fail outcome.

Payments: Stripe, test mode by default

This is a single one-time payment for a fixed-length challenge, not a subscription. There's no payment backend in this repo, so checkout hands off to one Stripe-hosted Payment Link; we never touch card data ourselves.

1. In the Stripe test mode dashboard, create one one-time price Payment Link, price = TOTAL_CHARGE_CENTS in moms-copy.js (stake + entry fee, currently $49.99). Do not use a recurring/subscription price, and do not create separate links for the stake and the fee, it's one checkout.
2. In the Payment Link's settings, set "After payment" → redirect to your own URL → https://getwalka.com/moms-success.
3. Paste the resulting https://buy.stripe.com/test_... URL into COHORT_PAYMENT_LINK.test in moms-copy.js.
4. To go live later: create the equivalent live-mode Payment Link, fill in COHORT_PAYMENT_LINK.live, and flip STRIPE_MODE from "test" to "live". That's the entire switch (also hides the test-mode card note on checkout, it's gated on STRIPE_MODE).

Card test number: 4242 4242 4242 4242, any future expiry, any CVC.

The stake mechanic

All in moms-copy.js, cohort only, no tiers or choices shown:

• PROGRAM_LENGTH_WEEKS: 4 weeks.
• COHORT_STAKE_AMOUNT_CENTS: $39.99 total stake, a cent under $40 on purpose (same under-the-round-number pattern as the main app's $19.99 entry), returned in full if you don't miss every day.
• ENTRY_FEE_CENTS: $10 total, platform revenue, not refundable. Marketed as "~$2.50/week" but charged as this one upfront amount, never billed weekly; a real weekly charge would make it a recurring subscription collected outside IAP, which this flow must not do, same invariant as the main app.
• MISS_AMOUNT_CENTS_PER_DAY: $2, applies from day one. No grace period, no free "life happened" passes, every missed day costs $2 (missing all 20 weekdays forfeits effectively the full $39.99 stake, one cent over on paper; the mechanic caps forfeiture at the stake itself). Money from missed days goes into the pool split among cohort members who finish, same mechanic as the main app's weekly cohorts. The checkout screen shows this as "-$2 from your stake," not a bare "$2," so it doesn't read as a separate charge due today.
• TOTAL_CHARGE_CENTS: stake + fee, what the single Payment Link actually charges ($49.99).

Prepare mode never charges anyone. If clearance_status !== "yes", there's no step goal to miss (the plan preview/checkout copy and the miss_cents field written to Supabase both reflect "not tracked"/"no goal yet" rather than the $2 figure) and, as of 2026-10, no Stripe checkout at all: the "Pay" button is replaced with "Reserve my spot," which skips the Payment Link entirely, upserts the lead with checkout_status: "reserved" and the email/name they entered, and shows an on-page "you're on the list" confirmation. Follow-up (emailing them once they're cleared, to come back and actually pay) is manual for now, there's no automated re-engagement built here. Earlier versions of this flow charged the full stake upfront in prepare mode too ("reserving a spot" with a refundable stake); that's been replaced because asking for a real card charge before someone can even start wasn't the right call.

The cohort step is no longer a choice (it was, until 2026-10; see the manual test checklist for the old pick-and-mismatch-warning behavior this replaced). It auto-places from weeks_postpartum, read-only (0–13 weeks -> 0–3mo, 13–26 -> 3–6mo, otherwise 6–12mo; pregnant always lands in "Due soon"; postpartum with no weeks answer, that field is optional, falls back to 0–3mo rather than leaving the group unresolved).

Data storage (Supabase)

Onboarding answers are upserted to Supabase after every step (so drop-offs are captured too, not just completions), using the local_id generated in the browser as the upsert key.

1. Run supabase/moms_leads.sql once in your Supabase project's SQL editor.
2. Fill in SUPABASE_URL and SUPABASE_ANON_KEY (Project Settings → API, the anon/public key only, never the service role key) in moms-copy.js.
3. View/export leads from the Supabase dashboard Table Editor (service role, bypasses RLS). Nothing in this page reads leads back, but the anon key can technically select its own row by local_id, that policy exists only because Postgres requires it to resolve upsert()'s ON CONFLICT under RLS, see the note in supabase/moms_leads.sql. Without it, every single upsert, including a brand-new row with nothing to conflict with, fails outright with a row-level security error. This isn't a hypothetical: it's exactly what silently broke lead capture for this flow until the select policy was added, so don't remove it as a "we don't need reads" cleanup.

Analytics events

All fire via the existing PostHog instance, prefixed moms_ (see EVENTS in moms-copy.js): moms_onboarding_start, moms_step_viewed, moms_step_completed, moms_dropoff, moms_home_viewed, moms_checkout_viewed, moms_checkout_started, moms_checkout_completed, moms_checkout_failed, moms_geo_blocked. The quiz-specific events (moms_clearance_answered, moms_motivation_chosen, moms_cohort_chosen, moms_prepare_reserved) were retired along with the quiz; a flag set up in PostHog around any of those is now dead.

Assumptions & open questions

• The checkout screen still charges the old stake/fee model, not the coaching subscription. As of 2026-10-11, the "Your stake" screen was removed from the funnel (replaced by "Your plan," a no-dollar-figures preview of goal/length/cohort/coach style) because its $39.99 stake + $10 entry fee language conflicted with a stated $24.99/mo or $199.99/yr coaching-and-community subscription offer. The checkout screen right after it was explicitly out of scope for that change and still shows the same stake/fee/total breakdown and still charges the one-time $49.99 via COHORT_PAYMENT_LINK, now with no screen above it explaining those numbers. This is a known gap, not an oversight: the checkout rework depends on deciding how the subscription is actually billed (see the architecture question below) before touching it.
• One-time Payment Links can't bill a subscription, by platform default, but Payment Links do support recurring prices (the "one-time only" rule earlier in this file was specific to the stake model, not a Stripe limitation): COHORT_PAYMENT_LINK can point at a recurring price once the checkout screen itself is reworked for the subscription (not yet done; see above). Stripe bills recurring charges automatically regardless of what this repo tracks; what's missing without a webhook is our own record of renewals/failures/cancellations.
• link-moms-subscriber (Edge Function, in the main stepr repo's supabase/functions/, not here) is the first piece of that: called from /moms-success right after the Stripe redirect, same "replaces a webhook, call it on return" pattern the main app's sync-subscription-status already uses. Payment Links don't hand back a customer/subscription id in the redirect URL, so it looks the Stripe Customer up by the email already on the moms_leads row and writes stripe_customer_id + subscription_status (mirrors Stripe's own subscription.status) back onto that row. Public, unauthenticated (the moms funnel never creates a Supabase session), gated only on knowing the row's local_id, same trust model as every other write here.
• Still not built: linking a moms_leads row to an actual app account. When someone downloads the app and signs up with the same email, nothing yet copies stripe_customer_id onto their new profiles row. That means extending handle_new_user(), the trigger that creates a profiles row for every signup app-wide, so it's deliberately held until there's a real recurring Payment Link and a tested link-moms-subscriber run to reconcile against, given the blast radius of a mistake there (every signup, not just moms subscribers). Once that exists, the main app's own (already built, called on cold start) picks up the real status from Stripe with no further moms-specific code.

Manual test checklist

• /moms with the PostHog flag off and no ?preview=1 shows the "not open yet" gate, no flow visible.
• /moms?preview=1 unlocks the flow on that device; ?preview=0 relocks it.
• From a US or Canadian IP (or a VPN set to one), /moms goes straight into the wizard as normal; a moms_leads row appears with country set to US/CA even before completing the first step.
• From a VPN set to a third country, /moms shows the "not available in your country yet" gate instead of the wizard; a moms_geo_blocked event fires in PostHog and the moms_leads row's country reflects that country with last_step: "geo_blocked".
• /moms?preview=1 from that same non-US/CA VPN still unlocks the full flow (preview bypasses the geo gate, not just the feature flag).
• Reload mid-flow → returns straight to the saved step with a "welcome back" banner instead of restarting from Step 1.
• Stage: pick pregnant, due-date field shows, no delivery type question.
• Stage: pick postpartum, weeks-postpartum + delivery type fields show.
• Clearance: yes → Goal step shows three pill choices (3,000 / 5,000 / 10,000 steps/day), none pre-selected; Continue stays disabled until one is picked.
• Clearance: not yet or not sure → kind message shown, Goal step shows prepare-mode copy with no numeric goal, nothing exercise-related is pushed.
• Stage postpartum, weeks postpartum 4 → Cohort step shows "You'll be grouped with: 0–3 months postpartum" as plain text, no pickable options and no way to change it.
• Stage postpartum, weeks postpartum left blank → Cohort step still shows "0–3 months postpartum" (the no-weeks fallback), not a blank or broken state.

General-audience flow (/start)

Same pattern as /moms above (quiz -> paywall -> inline Stripe checkout -> success page, no Supabase session, a local_id-scoped leads table), aimed at anyone rather than pregnancy/postpartum specifically. Files: start.html, start-copy.js, start-app.js, start-success.html, supabase/start_leads.sql.

The six questions

Goal, current average daily steps, a difficulty pick (easy/medium/hard), coach personality (princess/tough, same two personas the app already has), solo-or-group, and -- solo only -- a stake amount. The stake step is skipped entirely for a group pick: a shared weekly cohort has one fixed stake, not a per-user choice, so the paywall shows the cohort's real price instead of asking for one.

What's different from /moms

• Two charges, one card. Checkout confirms the $9.99/mo membership (Stripe Subscription, create-start-subscription-intent) and then, immediately after and without asking for card details again, the refundable stake (create-start-stake-intent, a one-time PaymentIntent against the same saved payment method). No Payment Link fallback for this funnel -- a Payment Link can't carry the second charge, so a Stripe.js load failure shows an error instead of degrading to a redirect.
• The group price is fetched, not invented. get-weekly-cohort-preview (public, no auth) returns the real next cohort's step goal, stake, entry fee, start date and spots left, read fresh from challenges the same way lib/weeklyCohort.ts's getNextJoinableCohort() does in the app. The stake actually charged is resolved the same way, server-side, inside create-start-stake-intent -- never trusted from the client.
• The app-side linking step moms's own notes called "separate and not yet built" is built here, as apply-pending-web-plan (an authenticated Edge Function, not a widened handle_new_user() trigger) plus hooks/usePendingWebPlan.ts in the main app, called once per signed-in session. It looks up start_leads by the signed-in user's email, re-verifies the stake PaymentIntent with Stripe, credits the wallet via the existing apply_credit('top_up', ...) RPC, and writes coach_style, fitness_goal, recommended_step_goal, weekly_mode, solo_stake and the subscriber columns onto the profile -- the same fields in-app onboarding already writes, so the existing home-screen cards (HomeFallbackCard, StartSoloCard) pick the plan up with no new screen. Idempotent via profiles.web_plan_applied_at.
• No geo gate, USD only, v1. Add a CAD price and the same middleware.js/cookie gate /moms uses if this ever needs Canada.

Manual test checklist

• Walk all six questions + contact on /start?preview=1; start_leads upserts after every step.
• Pick group: the stake step never appears; the paywall shows get-weekly-cohort-preview's real numbers (step goal, stake, spots left), not a user-editable amount.
• Pick solo: only $15/$25/$50/$100 are selectable; the paywall shows the chosen amount.
• Checkout with Stripe's 4242 4242 4242 4242 test card: both PaymentIntents succeed against the same Customer (check the Stripe test dashboard); start_leads has stripe_customer_id, stripe_subscription_id and stake_payment_intent_id all populated; redirect lands on /start-success.
• On a different device/browser, sign up in the app with the same email: apply-pending-web-plan applies on first cold start (check profiles.web_plan_applied_at, weekly_mode, coach_style, recommended_step_goal); the wallet shows the stake credited (credit_ledger, type = 'top_up', stripe_ref = the stake PaymentIntent id); re-opening the app doesn't credit it twice.
• Confirm /moms, /invite, /terms, /privacy are all unchanged.