Skip to content
mel — finance agent for couples

005 — Landing page architecture (Astro + SEO stack)

Status: Aceita (2026-06-03)

Update 2026-06-03: Mecânica de waitlist (form {email, coupleName}, fila, posição, “sobe na fila”) foi descontinuada. Ver ADR 010 — Landing final direct-to-WhatsApp. Stack Astro + Cloudflare Pages + D1 + Plausible continua válida pra landing estática + blog + referral attribution log.

Contexto

Section titled “Contexto”

CEO doc (decisão #9, 2026-06-03) crava “Landing PT-BR + waitlist” como primeiro move: meta 1000 casais em 30 dias, sinal go/no-go antes de queimar tempo no MVP. CEO doc #7 também trava em growth orgânico (K-factor 1.5, CAC ~R$0, bootstrap sem ads). Tradução técnica:

  1. SEO PT-BR long-tail é o canal primário — “app finanças casais BR”, “como dividir contas casamento”, “meta poupança casal”. Sem alavancagem de ads, ranking orgânico é o que move waitlist signups.
  2. Core Web Vitals viram ranking signal direto — Google penaliza LCP/CLS/INP ruins. Landing precisa rodar 95-100 no Lighthouse out-of-the-box ou perde no primeiro filtro.
  3. Blog PT-BR de conteúdo marketing — content marketing (decisão #7) precisa de pipeline Markdown leve, build incremental, OG images dinâmicas pra share.
  4. CTA waitlist + viral share — formulário simples (email + nome do casal), trigger “convida parceiro sobe na fila”. Backend de form leve.
  5. Bootstrap = custo zero — hospedagem free tier obrigatório, sem analytics pago, sem CMS pago.

O app principal (chat conversacional, cenários 008+) já tem stack travada no ADR 001: Next.js + Vercel AI SDK + clone do vercel/chatbot starter. Reusar o mesmo stack pra landing seria a tentação óbvia — mas Next.js carrega React runtime em toda página, perde 10-15 pontos de Lighthouse vs SSGs puros em conteúdo estático (benchmarks recentes mostram Next.js ~75 vs Astro >95 em slow-4G). Landing é content-heavy e quase 100% estática; pagar o custo de runtime de uma SPA framework não compensa.

Research feito (2026-06-03) cobrindo Astro 6, Next.js 15, Hugo 0.155, Eleventy 3.1/4.0-alpha, Qwik 1.19, Remix, Webflow, Framer, WordPress. Esta ADR consolida — sem reabrir benchmark.

Decisão

Section titled “Decisão”

Adotar Astro 6 como framework da landing, separado do app principal. Stack completa abaixo.

Rationale curto: Astro entrega 95-100 Lighthouse out-of-the-box (islands architecture, zero JS por default), content collections type-safe nativas pra blog Markdown/MDX, i18n routing oficial, integrações SEO maduras (@astrojs/sitemap, OG image gen, schema.org), TS nativo, deploy Vercel/Cloudflare/Netlify friction-free, e Apache-2.0 com bus factor sólido (Cloudflare adquiriu Astro em 2026, releases ativos — última major v6 estável early 2026). Trade-off vs Next.js (não unificar com app) é assumido: stack duplicado, mas o app é interativo (chat + tool-calling, ADR 001) e a landing é content-first — perfis de uso opostos justificam stacks separados.

Stack completa

Section titled “Stack completa”

Framework

Section titled “Framework”
  • Astro 6 (astro@^6) — SSG default, islands pra ilhas interativas (form de waitlist), content collections com schema Zod pra blog, i18n routing nativo (astro:i18n).
  • MDX via @astrojs/mdx — posts do blog podem ter componentes React/Astro inline quando precisar (gráficos, callouts).
  • Tailwind CSS via @astrojs/tailwind — alinha com vercel/chatbot starter do app (consistência visual entre landing e app).

Hospedagem

Section titled “Hospedagem”
  • Cloudflare Pages — free tier vence pra estática: bandwidth ilimitado, sem egress fee, 500 builds/mês, edge global. Vercel free é restritivo (proíbe uso comercial no Hobby) e $20/seat depois. Cloudflare $5/mo Pro só quando precisar de mais.
  • DNS no Cloudflare também (já é o registrar default da Cloudflare). Domínio mel.finance ou melfinance.com.br (CEO doc #1 sugere).
  • Edge functions Cloudflare Workers ficam disponíveis sem custo extra pra form backend custom se precisar.

Form backend (waitlist)

Section titled “Form backend (waitlist)”
  • Cloudflare Workers + D1 (DIY) — Worker recebe POST do form, valida (Zod), grava em D1 (SQLite no edge). Free tier: 100k req/dia + 5GB D1 = ~4M submissions. Custo zero, controle total, schema próprio (email, nome do casal, parceiro_email opcional, referrer pra K-factor tracking).
  • Plano B se DIY virar fricção: Formspree free tier (50 submissions/mês — bate cedo) ou Resend (3k emails/mo grátis) com inbox direto. Decisão diferida — começa DIY, troca se incomodar.
  • Trigger viral (“convida parceiro sobe na fila”) = lógica no Worker, fila implementada como timestamp + position calculada on-read.

Analytics

Section titled “Analytics”
  • Plausible managed cloud (free trial 30d, depois ~$9/mo @ <10k pageviews) OU self-hosted Plausible CE/Umami. Cookieless, sem banner LGPD/GDPR, dashboard limpo. Decisão final adiada — começa com Plausible free trial pra medir waitlist, decide self-host quando tiver dado.
  • Skip GA4 (cookie banner LGPD = friction, dashboard pesado, dados vão pra Google = mau alinhamento com posicionamento “couples privacy”).

SEO tooling

Section titled “SEO tooling”
  • @astrojs/sitemap — gera sitemap.xml no build, suporta hreflang pra i18n (PT-BR primário; EN futuro quando expandir).
  • src/pages/robots.txt.ts — robots dinâmico referenciando o sitemap (pattern oficial Astro).
  • Schema.org JSON-LD injetado via componente <SEO> em cada layout (Organization, WebSite, BreadcrumbList, Article pra posts do blog). Astro não gera automático — implementação manual via frontmatter (research confirma).
  • OG image generation via endpoint Astro (src/pages/og/[slug].png.ts) — gera card dinâmico por post/página usando satori + resvg. Ranking de share Twitter/LinkedIn (canal CEO doc #7).
  • @rafters/astro-meta (community, May 2026) — gera llms.txt, JSON-LD, GEO readability scoring no build. Avaliar quando aparecer caso de GEO (Generative Engine Optimization — ChatGPT/Perplexity surfacing).

Repo strategy

Section titled “Repo strategy”
  • Monorepo apps/landing + apps/app (npm workspaces). Mesmo repo do app, sibling de apps/app/ (futuro home do clone vercel/chatbot). Justificativa:
    • Compartilha tipos via packages/shared/ quando aparecer (ex: domain de waitlist signup eventualmente vira couple no app).
    • Conteúdo do blog pode referenciar features do app sem duplicar copy.
    • Deploy independente: Cloudflare Pages só observa apps/landing/; Vercel só observa apps/app/.
  • Skip repo separado: cross-link manual entre repos é fricção sem ganho. Só vira separado se for vendido/spinoff (cenário M&A do CEO doc — improvável antes do exit).

Skip explícito (avaliados e descartados)

Section titled “Skip explícito (avaliados e descartados)”
  • Next.js pra landing — mesmo stack do app, reuso de componentes/types. Perde 10-15 pontos Lighthouse vs Astro em conteúdo estático (React runtime mandatório por página). SEO long-tail (canal #1) penaliza. Rejeitado: o ganho de “stack único” não compensa o custo de ranking orgânico.
  • Hugo — fastest build (Go), multilingual nativo, SEO benchmark forte. Rejeitado: template syntax (Go templates) é estranha pro projeto TS-native; componentes Astro/MDX são muito mais ergonômicos pra autoria. Hugo ganharia se o blog tivesse 10k posts; pra <100 posts a diferença de build não importa.
  • Eleventy (11ty) — JS SSG simples, ativo (v3.1 stable May 2025, v4-alpha mar/2026, joined Font Awesome 09/2024 = bus factor sólido). Rejeitado por margem fina: Astro tem islands prontas pra widget de form, content collections com Zod (vs config manual no Eleventy), e ecosistema de integrações SEO mais maduro. Eleventy seria escolha se a landing fosse 100% estática sem nenhuma ilha interativa.
  • Qwik / QwikCity — resumability é elegante (v1.19 latest, beta-ish em produção). Rejeitado: overkill pra landing estática. Resumability paga em apps interativos complexos; pra landing + blog, Astro islands cobre os 5% interativos com menos surface conceitual.
  • Remix — full-stack TS, ótimo pra apps. Rejeitado: nasceu pra apps com data loading, não pra content site. Astro tem mais features de SEO/content out-of-the-box.
  • Webflow / Framer — no-code visual. Rejeitado: (a) custo mensal recorrente (Framer/Webflow ~$15-30/mo por site), (b) Framer perde em SEO semântico (HTML não-clean), Webflow é decente mas trava lock-in de exportação, (c) editar copy via UI quebra workflow git-based do projeto. Bootstrap diz “custo zero”; SaaS visual conflita.
  • WordPress — SEO maduro, plugins infinitos. Rejeitado: PHP + MySQL + admin pesado = surface enorme pra manter, headache de segurança (plugins desatualizados), zero alinhamento com stack TS-native. Bom pra agência que vende sites WP; péssimo pra projeto TS solo.

Consequências

Section titled “Consequências”

Positivas:

  • Lighthouse 95-100 out-of-the-box vira ranking signal positivo no Google (Core Web Vitals como signal direto).
  • Blog Markdown/MDX type-safe via content collections — autor escreve .md com frontmatter validado por Zod, sem CMS externo.
  • Free tier total (Cloudflare Pages + Workers + D1 + Plausible trial) = R$0/mês até validar waitlist. Casa com bootstrap (CEO doc #6).
  • i18n routing nativo destranca expansão futura PT-BR → EN sem refactor (mesmo que CEO doc #2 trave em BR-only por enquanto — hreflang é grátis).
  • Stack TS-native (Astro, Cloudflare Workers, Tailwind) compartilha mental model com o app. Switch de contexto barato.
  • Repo monorepo permite compartilhar tipos/copy entre landing e app quando aparecer.
  • Astro deploy em Cloudflare Pages é zero-config (wrangler.toml + git push). Sem CI custom até precisar.
  • Cookieless analytics (Plausible) elimina banner LGPD = -1 fricção no funil de conversão.

Negativas / Trade-offs:

  • Stack duplicado (Astro pra landing + Next.js pra app) — dois frameworks pra entender. Mitigação: perfis de uso opostos justificam (content-first vs interactive-first). Compartilhamento via packages/shared/ quando aparecer.
  • Cloudflare Pages tem deploy quirks vs Vercel (Vercel é mais polido pra Next.js especificamente). Mitigação: Astro funciona bem em ambos; trocar pra Vercel/Netlify é mudar adapter no astro.config.mjs se Cloudflare incomodar.
  • DIY waitlist (Cloudflare Worker + D1) = código próprio pra escrever/manter, mesmo que pequeno. Mitigação: Worker é ~50 LOC; alternativa Formspree free cap 50/mês quebra cedo na meta de 1k em 30d.
  • OG image gen via satori/resvg adiciona complexidade — pode adiar pra v2 e usar OG image estática inicial. Não bloqueia launch.
  • Astro 6 é major recente (early 2026) — algumas integrações podem ter rough edges. Mitigação: docs oficiais sólidas, migration path documentado, fallback pra v5.x se algo travar.
  • Schema.org JSON-LD manual — Astro não gera automático; cada layout precisa injetar. Mitigação: componente <SEO> único cobre 90% dos casos.
  • Não unificar com Next.js do app = mais um deploy pra orquestrar, mais um repo de dependências pra atualizar. Aceito.

Alternativas consideradas

Section titled “Alternativas consideradas”
  • Next.js (unificar com app) — reuso de componentes, single stack. Perde 10-15 pontos Lighthouse em content; SEO long-tail (canal #1 CEO doc) penaliza. Rejeitado.
  • Hugo — fastest build, multilingual maduro. Template syntax Go vs componentes TS = mismatch ergonômico. Rejeitado.
  • Eleventy (11ty) — JS SSG ativo, simples. Astro ganha por margem em islands prontas + Zod content collections + integrações SEO mais maduras. Rejeitado por margem fina; manter no radar se Astro frustrar.
  • Webflow/Framer — visual builder, lock-in SaaS, custo mensal. Conflita com bootstrap. Rejeitado.

Referências

Section titled “Referências”