Skip to content
mel — finance agent for couples

010 — Landing final direct-to-WhatsApp (drop waitlist mechanic)

Status: Aceita (2026-06-03)

Contexto

Section titled “Contexto”
  • ADR 005 (Landing stack) crava waitlist como primeiro move: meta 1k casais em 30d, form {email, coupleName}, fila com posição, share link “convida parceiro sobe na fila”.
  • Em 2026-06-03 CEO reavaliou e killou a fila: “bobeira ter waitlist, vamos fazer landing final direta whats”.
  • Hipóteses por trás do kill:
    • Pre-launch waitlist adiciona fricção pra pouco sinal (email não é commit, só intenção).
    • Whats já é o canal final (ADR 007). Lance direto evita re-engajamento (email + click + manda msg).
    • K-factor viral funciona melhor pós-uso (casal compartilha o que já está usando) do que pré-uso (compartilha lista de espera abstrata).
    • Anonymous-first (ADR 006) já garante zero fricção — extender pra “zero captura web” é coerente.

Decisão

Section titled “Decisão”

Adotar landing final direta:

  1. Landing page = produto pronto, não pre-launch. Hero curto + CTA primária wa.me/<bot>?text=oi. Sem form, sem email, sem captura web.
  2. Waitlist mechanic removida integralmente. Sem Waitlist/WaitlistEntry/position/register/linked. Context waitlist/ → referrals/.
  3. Referral attribution preservado sem mecânica de fila. ShareToken permanece. Referrals.issue(ownerHouseholdId) (idempotente por owner) + Referrals.attribute(...) (append-only, silent on invalid). Cenário 016 refatorado pra Referral attribution (sem fila).
  4. Onboarding direto via whats. Primeira msg oi cria Household. Opcional prefix ref-<token> dispara attribution. bootstrapFromOnboardingToken da HouseholdLookup port removido; substituído por bootstrapFromChat({chatId, senderId, referralToken?}).
  5. Landing stack (ADR 005) mantém Astro + Cloudflare Pages — só as partes interativas (form, waitlist API, fila JS) saem. Blog SEO + share link UX + ChatEmbedTeaser continuam.

Consequências

Section titled “Consequências”

Positivas:

  • 1 less hop no funnel (visitor → CTA → whats, sem email + click + msg).
  • 0 PII coletado pela web (anonymous-first reforçado).
  • Domain mais simples (referrals/ tem 2 verbos: issue + attribute; waitlist/ tinha 4+ com edge cases de email idempotence/normalization).
  • Specs e2e mais enxutos (sem form, sem mock backend de waitlist).
  • ADR 005 stack continua válido pra parte estática (landing + blog). Cloudflare D1 muda de “fila persistida” pra “referral attribution log”.

Negativas / trade-offs:

  • Sem captura de email = sem canal de re-engajamento web pra quem clicou e não mandou msg.
  • Métrica “1k casais waitlist em 30d” (CEO doc #9 original) precisa redefinir: agora é “1k casais ativos em 60d” (>= 1 conversa concluída).
  • Re-engajamento depende 100% do whats (mais ban-risk surface via msgs proativas).

Não-impactos:

  • ADR 006 (anonymous-first) preservado intacto.
  • ADR 007 (whats canal único, Baileys) preservado.
  • Cenários 008-015 (domain core) intactos.
  • Cenário 008 (chat com agente) intacto.
  • Cenário 018 (onboarding zero-state) intacto — só muda como o user chega no fluxo (direto vs via waitlist).

Alternativas rejeitadas

Section titled “Alternativas rejeitadas”
  • Manter waitlist como pre-launch — desuso provável, fricção pra pouco sinal. CEO killou.
  • Híbrido (waitlist opcional + entry direto) — confunde UX. Forçar uma escolha.
  • Captura de email como upgrade pós-uso — possível futuro pra multi-device login, mas não pre-launch / pre-engagement. Adia até aparecer o caso real.

Referências

Section titled “Referências”