ADASH em
3 semanas:
como construí
um SaaS
do zero.

Quatro ferramentas.
Nenhuma decisão boa.

O cliente gerenciava toda a operação de marketing e vendas com um conjunto de ferramentas que nunca foram pensadas para trabalhar juntas: Meta Ads em um lugar, Google Ads em outro, CRM em planilha no Google Drive e relatórios exportados para o Excel toda semana.

O problema visível era o tempo perdido. Mas o problema real era mais sutil: decisões de investimento sendo tomadas com dados que chegavam sempre atrasados. Quando você demora dois dias para consolidar o relatório da semana passada, você já está três dias atrasado.

O briefing inicial pedia um "dashboard de marketing". Depois de três horas de conversa, ficou claro que o que eles precisavam não era de um painel. Era de uma única fonte de verdade para toda a operação.

Por que construir
do zero, não customizar.

A primeira pergunta que qualquer dev honesto faz nesse tipo de projeto: isso não resolve com Notion + Zapier + um bom template de Google Data Studio?

Às vezes resolve. Nesse caso, não. Os motivos:

• 01O cliente tinha nomenclatura própria para estágios do funil. Ferramentas off-the-shelf não dobram para isso sem gambiarra que quebra quando você atualiza o plano.
• 02A integração entre CRM e mídia paga precisava de lógica de negócio específica: atribuição, regras de estágio, alertas baseados em performance relativa, não absoluta.
• 03O agente de IA não seria possível em cima de uma ferramenta de terceiro. Precisava de acesso direto aos dados, não a uma camada de exportação.
• 04Custo de longo prazo: ferramentas SaaS empilhadas somam rápido. Uma solução própria tem custo de infraestrutura, não de licença por seat.

Stack escolhido: React + TypeScript + Vite no front-end, integração direta com a API do Meta Ads e Google Ads, base de dados própria para o CRM, e Claude como motor do agente de IA.

Design de produto,
não de dashboard.

A maioria dos dashboards falha por um motivo que não é técnico: eles são construídos como espelhos de banco de dados, não como ferramentas de decisão. Você vê os dados organizados da forma que o sistema os armazena, não da forma que você os usa para pensar.

Antes de abrir o Figma, mapeei o fluxo real de tomada de decisão do time. Que pergunta eles faziam primeiro quando abriam o computador de manhã? Com que frequência consultavam cada tipo de dado? Quando um número precisava de contexto de outro módulo para fazer sentido?

Três princípios guiaram o design:

• AHierarquia de informação por frequência de uso, não por importância percebida. O que o time consultava toda manhã ficou no topo. O que consultava uma vez por semana ficou dois cliques atrás.
• BContexto cruzado visível sem navegação. Quando você está vendo performance de mídia, o funil de vendas desse mesmo período aparece colapsado ao lado, você expande se precisar, sem trocar de tela.
• CTermos do negócio, não da ferramenta. O CRM não chamava "Lead" de lead: chamava pelo nome que eles usavam internamente. Soa óbvio, mas a maioria das ferramentas força você a aprender a nomenclatura delas.

IA que responde,
não que gera ruído.

O agente de IA foi o módulo mais delicado, não pela implementação técnica, mas pela definição de escopo. A pergunta errada é "o que a IA pode fazer?". A pergunta certa é "qual é a tarefa específica que o usuário faz hoje de forma manual que a IA resolve melhor do que qualquer interface?"

No caso do ADASH, a resposta era clara: interpretação de relatórios semanais. Toda sexta, alguém passava 45 minutos olhando para números e tentando articular o que eles significavam em linguagem natural para o time de vendas. Isso é exatamente o que um LLM faz bem.

O agente tem acesso direto ao contexto da conta: métricas de mídia, estágios do funil, histórico de campanhas, e responde a perguntas em linguagem natural. Não é um chatbot genérico. Ele conhece o negócio.

Três regras que guiaram a implementação:

• 01O agente só fala sobre o que ele sabe. Sem especulação. Se o dado não está no contexto, ele diz que não tem a informação.
• 02Toda resposta vem com a fonte. O usuário pode verificar o número bruto se quiser. Confiança se constrói com transparência, não com respostas fluentes.
• 03O agente não toma decisões. Ele apresenta contexto e indica implicações. A decisão fica com o humano.

O que aconteceu
em cada semana.

Os erros
que valem documentar.

Todo projeto tem pelo menos uma decisão que você tomaria diferente na segunda vez. No ADASH foram duas:

Comecei o módulo de relatórios cedo demais

Iniciei a implementação do gerador de PDF na semana 4, antes de ter o design final dos outros módulos consolidado. Resultado: tive que refatorar parte da estrutura de dados quando mudei o layout do dashboard na semana 5. Não foi crítico, mas custou meio dia que não estava no planejamento.

Lição: módulos de output (relatórios, exportações, notificações) devem ser os últimos a serem implementados, porque eles dependem de como os dados estão estruturados nos módulos de core.

Subestimei o tempo de ajuste do agente

Implementar o agente de IA tecnicamente levou dois dias. Fazer ele se comportar da forma certa, responder com o tom correto, não alucinar, saber quando dizer "não sei", e isso levou mais uma semana de ajustes de prompt e testes com dados reais.

Lição: em projetos com LLM, separe "implementação" de "calibração". São fases distintas. A calibração nunca está no escopo inicial e sempre cabe no prazo só se você reservar tempo para ela explicitamente.

O que a equipe
tem hoje.

O ADASH está em produção há meses. O time usa todos os cinco módulos diariamente. O tempo de análise semanal passou de horas para menos de 20 minutos. O agente de IA é consultado antes de toda reunião de performance.

Mas o resultado mais importante não está em nenhuma dessas métricas: eles pararam de usar planilha. Quando uma equipe migra permanentemente de um fluxo antigo para uma ferramenta nova, sem ser forçada a isso, é porque a ferramenta está resolvendo um problema real da forma certa.

Esse é o teste que uso para avaliar se um produto digital funcionou.