ForeverCount: construindo e crescendo um SaaS de consumo

Construí o ForeverCount junto com um parceiro, que cuidou principalmente do frontend. Meu lado era tudo por trás e ao redor disso: a direção de produto, o backend (microsserviços Python em AWS Lambda), o modelo de dados (DynamoDB) e o storage (S3), a integração de pagamento PIX com um banco brasileiro, o e-mail transacional e de ciclo de vida, o pipeline de analytics e a estratégia de growth em cima disso. Ninguém nos entregou um escopo, a gente decidia o que construir, subia, media e iterava.

• Frontend: Next.js (React, TypeScript) na Vercel, o criador da página, o checkout e a abertura animada do presente.
• Backend: microsserviços Python em AWS Lambda atrás do API Gateway, criação/edição de páginas, lógica de preço, geração de PIX, slugs, OTP por e-mail e aviso de leitura.
• Dados & storage: DynamoDB (pedidos e páginas, com GSIs por status e lookup) e S3 (conteúdo das páginas, fotos, QR Codes, cartões-presente em PDF).
• Pagamentos: PIX via Banco Inter, geração de QR dinâmico e um webhook autoritativo server-side (mTLS) que confirma o pagamento e reconcilia o pedido pelo id da transação. Dinheiro real, reconciliação real.
• Jobs assíncronos: EventBridge para trabalho agendado, limpeza de páginas expiradas e lembretes de e-mail temporizados.
• E-mail: Resend para transacional e ciclo de vida, com webhooks verificados por Svix alimentando entrega / abertura / clique de volta no analytics.
• Analytics: PostHog com pipeline de eventos próprio e queries em HogQL; dashboards feitos para serem lidos todo dia.

A engenharia colocou o produto no ar. A parte que eu tinha de ponta a ponta era tornar o growth mensurável e agir em cima disso.

• Instrumentei o funil de ponta a ponta, criação → ativação → visão da oferta → checkout → PIX gerado → pago, com uma chave de identidade estável entre client e server.
• Achei e corrigi um ponto cego crítico. O caminho de checkout que de fato gerava vendas não emitia eventos de client, então o funil media o caminho que não convertia e era cego ao que convertia. Movi os eventos críticos para o server, no ponto único onde o PIX nasce, garantindo ordem e cobertura, independente do caminho, espelhando o webhook autoritativo de pagamento.
• Adicionei segmentação por faixa de preço em cada evento do funil (desconto vs. win-back vs. preço cheio) para conseguir medir se o desconto realmente movia a conversão, em vez de adivinhar pelo valor.
• Construí fluxos de ciclo de vida & recuperação: entrega instantânea do código PIX, lembretes temporizados, um e-mail reativo de "seu presente acabou de ser aberto" e win-back pós-expiração, cada um atribuído à campanha que gerou a venda.
• Pratiquei estatística honesta. Com poucas vendas por semana, tomei cuidado de separar sinal de ruído de amostra pequena, para que uma semana fraca nunca fosse confundida com um funil quebrado.
• Minerei o próprio conteúdo. Rodei uma análise agregada sobre milhares de cartas escritas pelos usuários para achar oportunidades de produto: temas de fé / cristãos apareciam em 40–59% das cartas (um segmento não atendido), o teto de uma foto no grátis previa upgrades melhor que o tamanho da carta, e um uso emergente de "presente de aniversário / ocasião" apontava um mercado bem além de casais.

• Diagnostiquei o gargalo real, não o presumido. Os dados instrumentados mostraram que o vazamento estava entre ver a oferta e iniciar o checkout, não no abandono de pagamento, que era a suposição de trabalho. Confiar no dado em vez da intuição mudou o roadmap.
• Navegamos uma evolução completa de precificação. O produto rodou um modelo de alto volume e preço baixo em 2025 (R$ 4,99 era o preço dominante, ~1.100 vendas nessa faixa) e depois migrou para um modelo de preço mais alto, R$ 24,90, com todos os trade-offs de volume e mensagem que isso implica.
• Os aprendizados honestos: em volume baixo, medição rigorosa vence tática esperta; o mercado real de um produto pode diferir do seu posicionamento (casais vs. qualquer ocasião); e ser dono de algo de ponta a ponta, de webhooks de PIX a estatística de funil, é o jeito mais rápido de aprender como decisões de engenharia viram receita.

O ForeverCount foi encerrado em 2026. Este case study usa apenas métricas agregadas e páginas de demonstração, nenhum dado de cliente.