# Email na Caixa de Entrada: Como o EmailHacker.ai Resolveu em 5 Rodadas o Problema que Gestores Levam Horas
Na noite de 20 de março de 2026, uma sexta-feira, 150 pessoas assistiram ao vivo enquanto o EmailHacker.ai tentava fazer um e-mail cair na caixa de entrada principal do Gmail. Foram 4 horas e 47 minutos de stream, 6 terminais de Claude Code rodando em paralelo, e no final a receita acumulada do projeto subiu para R$1.860. Essa é a história do dia em que o teste de entregabilidade deixou de ser um trabalho manual.
R$1.860 e o Problema da Aba Promoções
Quando a stream 3 começou, o EmailHacker.ai já acumulava R$1.860 em vendas rastreadas por email marketing, com 103 usuários cadastrados e 22 contas ativas conectadas ao ActiveCampaign. O primeiro colocado no leaderboard interno tinha 16 vendas atribuídas. Esses números eram reais, exibidos no dashboard ao vivo, atualizados a cada webhook da Hotmart.
Mas havia um problema que nenhuma venda resolvia: os e-mails disparados pelo EmailHacker.ai estavam caindo na aba Promoções do Gmail. Para quem não trabalha com email marketing, isso pode parecer irrelevante. Para quem trabalha, é a diferença entre uma taxa de abertura de 8% e uma de 25%. A aba Promoções é onde os e-mails vão morrer silenciosamente, enterrados entre notificações de marketplace e cupons de desconto.
O EmailHacker.ai já conseguia gerar e-mails com 5 agentes de IA em paralelo: um para briefing, um para estratégia, um para subject line, um para copywriting e um para o HTML final. O disparo funcionava via API do ActiveCampaign, usando segmentação 1-a-1 para garantir que o servidor correto enviasse a mensagem. Tudo isso estava operacional desde a stream anterior. O que faltava era a última milha: garantir que o e-mail chegasse onde o destinatário realmente olha.
Email Azul: 5 Rodadas até a Caixa de Entrada
O Email Azul nasceu de uma votação ao vivo. Os 29 espectadores que estavam online no início da stream puderam escolher entre 4 funcionalidades: Email Azul (teste de entregabilidade), OpenClaw (WhatsApp), votação de features e report de bugs. O Email Azul venceu com margem expressiva.
O conceito por trás do Email Azul é direto: o EmailHacker.ai cria uma conta sentinela no Gmail ([email protected]), integrada via Gmail API. Quando o gestor quer testar um e-mail antes de disparar para a base inteira, o sistema envia automaticamente para essa conta sentinela e monitora em qual aba o e-mail caiu. Se caiu em Promoções ou Spam, o sistema reescreve o e-mail e tenta de novo. Máximo de 5 rodadas. O primeiro que cair na caixa de entrada principal vence.
As 5 rodadas de otimização seguem uma sequência fixa: rodada 1 com o e-mail original como baseline, rodada 2 com subject line otimizada, rodada 3 com conteúdo suavizado, rodada 4 com redução de links e imagens, e rodada 5 com alteração do pre-header e formato. Se nenhuma das 5 tentativas chegar na inbox, o problema é de domínio ou IP do servidor, e o EmailHacker.ai gera um relatório explicando isso ao gestor.
A implementação ao vivo não foi linear. A primeira tentativa falhou porque o sistema estava usando o fluxo de teste do ActiveCampaign, que envia por um servidor diferente do servidor real de disparo. Esse é um erro clássico que gestores de email marketing cometem diariamente: o botão "enviar teste" do ActiveCampaign usa um servidor separado, o que significa que o resultado do teste não reflete a entregabilidade real.
O EmailHacker.ai corrigiu isso criando sua própria segmentação 1-a-1 no ActiveCampaign com o e-mail sentinela como único contato. Dessa forma, o disparo de teste sai pelo mesmo servidor que o disparo real, gerando um resultado fiel. Na segunda rodada de testes, o sistema conseguiu enviar e monitorar corretamente. O e-mail caiu em Promoções nas primeiras tentativas, mas na rodada final, com pre-header ajustado e conteúdo otimizado pelo Claude AI usando um banco de mais de 70 frases inbox-safe para o mercado brasileiro, o e-mail chegou na caixa de entrada principal.
O tempo entre o início do desenvolvimento e o primeiro e-mail na inbox foi de aproximadamente 3 horas. O delay do ActiveCampaign para enviar campanhas agendadas (mais de 3 minutos em alguns casos) exigiu que o timeout de monitoramento fosse aumentado de 30 segundos para 10 minutos. Cada detalhe desses foi resolvido ao vivo, com o código sendo commitado em produção durante a stream.
6 Terminais em Paralelo: O Formato que Mudou Tudo
A stream 3 marcou a consolidação de um formato de desenvolvimento que o EmailHacker.ai usa desde o início: múltiplos terminais de Claude Code rodando tarefas simultâneas. Nessa noite foram 6 terminais ativos, cada um com uma tarefa diferente. Um terminal trabalhava no Email Azul, outro no OpenClaw (integração WhatsApp), outro na votação de features, outro no report de bugs, outro no sistema de indicação, e um sexto servia como orquestrador geral.
O modelo de uso é deliberado. O terminal principal roda Claude Opus como orquestrador, consumindo mais tokens mas mantendo contexto completo do projeto. Os terminais secundários rodam Claude Sonnet para tarefas mais simples e paralelizáveis. O resultado visível no painel de usage: após 5 horas de desenvolvimento intenso, apenas 9% do limite semanal de tokens havia sido consumido. Isso acontece porque o Sonnet consome significativamente menos créditos que o Opus, e a maior parte do trabalho paralelo roda em Sonnet.
Na prática, enquanto o Email Azul estava esperando 10 minutos pelo resultado do monitoramento do Gmail, os outros terminais já estavam criando tabelas no Supabase para o sistema de indicação, implementando a UI de votação de features e configurando o MCP Server do OpenClaw para reconhecer telefones de usuários. Esse paralelismo não é apenas eficiência técnica. Para quem assiste a stream, significa que sempre há algo acontecendo na tela, o que explica por que 150 pessoas ficaram até depois da meia-noite numa sexta-feira.
Sistema de Indicação, Bugs Gamificados e Votação
Além do Email Azul, 4 outras funcionalidades foram construídas do zero durante as 4 horas e 47 minutos da stream 3 do EmailHacker.ai.
O sistema de indicação gera um link único por usuário. Quando o indicado se cadastra, o indicador recebe créditos. A tabela de referrals foi criada no Supabase com RLS (Row Level Security), e o fluxo completo funciona assim: o usuário copia seu link no dashboard, o indicado acessa o site onde um cookie registra o código, passa pelo signup, e ao conectar o ActiveCampaign, o indicador recebe 50 créditos. O indicado recebe as quests normais de onboarding mais um bônus. Total potencial por indicação completa: 100 créditos. Sem limite de indicações.
O report de bugs com gamificação transforma o trabalho de QA em incentivo comunitário. Quando um usuário reporta um bug pelo dashboard do EmailHacker.ai e o administrador confirma que é um bug real, o reporter ganha 20 créditos. Se o bug é resolvido, mais 40 créditos extras. O badge vermelho na sidebar mostra bugs abertos, criando urgência visual.
A votação de features permite que qualquer usuário sugira uma funcionalidade e vote nas sugestões dos outros. Lista ordenada por votos, publicação direta sem fila de aprovação, 1 voto por pessoa por sugestão. Quando o administrador marca uma sugestão como implementada, o autor da ideia ganha 100 créditos. Isso cria um loop onde a comunidade direciona o roadmap e é recompensada por participar.
Durante a stream, 2 pessoas foram indicadas com sucesso, gerando 20 créditos para o indicador. O sistema de bugs recebeu os primeiros reports ainda durante a live. E a votação de features já tinha a primeira sugestão: "Integração com Eduzz". Tudo isso construído em paralelo, de código zero a produção, em menos de 5 horas.
O Ataque: 24 Mil Contas Fake em 40 Minutos
Por volta das 2 horas da manhã, quando a stream já estava no modo final de deploy, alguém começou a atacar o EmailHacker.ai. Em aproximadamente 40 minutos, mais de 24.000 cadastros foram criados usando contas com domínio @loadtest.dev, uma ferramenta de teste de carga. O objetivo era claro: derrubar o sistema ou poluir a base de dados.
O ataque foi detectado ao vivo. O dashboard do EmailHacker.ai mostrava os cadastros entrando em velocidade anormal, todos com o mesmo padrão de domínio. A resposta foi implementada durante a stream: um rate limit de 5 signups por hora por IP, bloqueio automático de domínios conhecidos de teste de carga, e identificação do IP de origem. O sistema voltou ao normal em menos de 30 minutos após a detecção.
O incidente gerou uma funcionalidade permanente: o EmailHacker.ai agora tem proteção anti-spam no signup com validação de domínio, rate limiting por IP e monitoramento de padrões anômalos. O IP do atacante foi registrado para providências posteriores. A base de dados foi limpa, removendo os 24.000+ registros falsos.
Para o contexto de build-in-public, o ataque foi paradoxalmente positivo. Mostrou ao vivo que o sistema era resiliente o suficiente para se recuperar, e a implementação da segurança em tempo real demonstrou a velocidade de desenvolvimento com Claude Code. Os espectadores assistiram ao problema e à solução acontecerem na mesma sessão.
150 Pessoas ao Vivo: O Pico da Série
A stream 3 do EmailHacker.ai atingiu 150 espectadores simultâneos, o maior número da série até aquele momento. A stream anterior havia atingido um pico de 15 espectadores simultâneos. Em 3 dias de transmissão, o canal acumulou mais de 10.000 visualizações totais, com a stream 3 ultrapassando 5.000 views e 286 likes.
Os 103 usuários cadastrados no início da noite subiram para 130 durante a stream. Desses 130, 23 já tinham contas ActiveCampaign conectadas e pelo menos 1 funil de e-mail ativo. O EmailHacker.ai estava adquirindo usuários em tempo real, durante a própria transmissão, com o produto sendo construído ao vivo.
O formato build-in-public do EmailHacker.ai funciona como um loop de aquisição: a stream demonstra o produto, novos usuários se cadastram durante a live, reportam bugs que são corrigidos na mesma sessão, sugerem features que entram na votação, e indicam amigos usando o sistema de referral construído naquela mesma noite. Cada stream alimenta a próxima.
A receita acumulada de R$1.860 com 19 vendas atribuídas a email marketing em 3 streams representava 0,186% da meta de R$1.000.000. Número pequeno em valor absoluto, mas a curva era ascendente: R$0 na Stream 1 (lançamento sem receita), R$337 na Stream 2, R$1.860 na Stream 3. O primeiro colocado do leaderboard já tinha 16 vendas atribuídas somente a email. A ferramenta estava se provando não apenas como produto, mas como canal de aquisição e como demonstração ao vivo do que email marketing automatizado pode fazer.