Construí um app interno de diagnóstico em 1 mês sem escrever uma linha de código

Construí um app de diagnóstico de automação para qualificação de leads em 1 mês, usando Claude Code, Astro e Vercel, sem escrever uma linha de código manualmente. Está no ar em mapeamento.expertintegrado.com.br e hoje é parte do nosso processo comercial.

Qual problema eu precisava resolver?

Leads chegavam sem qualificação estruturada. A gente tinha reuniões de diagnóstico que dependiam totalmente da memória do vendedor e das perguntas que ele lembrava de fazer naquele dia. Às vezes saíam completas, às vezes saíam com 60% do que precisávamos saber pra fazer uma proposta boa.

Não era preguiça do time. Era falta de ferramenta. Sem um formulário estruturado que guiasse o lead antes da reunião, a gente sempre dependia de improvisar ao vivo, e improvisar ao vivo tem custo: reunião mais longa, proposta mais genérica, taxa de conversão menor.

O número que me incomodava era esse: das reuniões de diagnóstico que a gente fazia, a taxa de proposta enviada era de cerca de 70%. Das propostas enviadas, 40% convertiam. Isso significa que de cada 10 reuniões, fechávamos 2,8 contratos. Eu queria saber quanto desse atrito era qualificação ruim antes da reunião.

Por que não contratar uma agência ou um dev?

Três razões práticas, não ideológicas.

Primeira: o prazo. Eu queria testar a hipótese em 1 mês, não em 3. Briefing, proposta, alinhamento, desenvolvimento, revisão, deploy. Com agência, 1 mês vira 3 facilmente.

Segunda: o custo. Para uma ferramenta interna de uso comercial, com incerteza sobre se ia funcionar do jeito que eu imaginava, pagar R$15k a R$40k pra uma agência não fazia sentido. Eu precisava de um MVP que eu pudesse ajustar semanalmente, não de um entregável com escopo fechado.

Terceira, que é a mais honesta: eu queria entender o que era possível fazer sozinho com IA. Sou mentor de IA no G4 Educação e não consigo ensinar o que não vivi. Precisava de um caso real, com atrito real, pra saber o que funciona de verdade e o que é marketing de ferramenta.

Como os 4 pilares do Vibe Coding aparecem nesse projeto?

Vibe Coding tem quatro pilares: especificação em linguagem natural, iteração por texto antes de código, revisão humana de decisão (não de sintaxe) e orquestração de ferramentas especializadas. Esse projeto é um caso de escola dos quatro.

Especificação em linguagem natural: antes de abrir o Claude Code, escrevi um documento de 2 páginas descrevendo o que o formulário precisava fazer, qual a sequência de perguntas, como os dados deveriam ser salvos e qual era a UX esperada pelo lead. Não escrevi uma linha de código nessa etapa. Escrevi texto.

Iteração por texto antes de código: quando algo não funcionava como eu queria, a primeira pergunta era “minha spec está clara?” antes de “meu código está errado?”. Na maioria dos casos, o problema era ambiguidade no que eu havia pedido.

Revisão humana de decisão: eu não revisava sintaxe de JavaScript. Eu revisava se a experiência do lead estava boa, se as perguntas faziam sentido na ordem que apareciam, se o design comunicava confiança. Decisão de produto, não decisão técnica.

Orquestração de ferramentas: Claude Code gerou o código, Astro serviu como framework, Vercel fez o deploy automaticamente a cada push, e a integração com Pipedrive aconteceu via MCP nativo do Claude Code. Eu orquestrei. Não codifiquei.

Semana a semana: o que construí e como?

Semana 1: a spec. Passei a semana inteira escrevendo o documento de especificação. Não é exagero dizer que essa semana foi a mais importante do projeto. Defini: quantas seções o formulário teria, qual a lógica de progressão entre seções, quais campos eram obrigatórios, como os dados seriam armazenados, qual era a mensagem de confirmação pós-envio e como o lead voltaria pra uma página de agradecimento com próximos passos claros. Esse documento virou o prompt de entrada pra tudo que veio depois.

Semana 2: estrutura inicial e ajustes de voz. O Claude Code gerou a estrutura do projeto Astro, os componentes do formulário e a lógica de validação dos campos. Em dois dias eu tinha algo funcionando localmente. Os três dias seguintes foram de ajuste de voz e design: as perguntas estavam tecnicamente corretas mas soavam como formulário de RH, não como uma conversa de diagnóstico. Reescrevi os textos, ajustei o tom, pedi ao Claude Code que aplicasse as mudanças no componente. Deploy no Vercel no fim da semana pra ter uma URL pra testar com o time.

Semana 3: integração com Pipedrive e testes. Essa foi a semana mais técnica. Precisava que cada envio do formulário criasse automaticamente um contato e um deal no Pipedrive com as respostas mapeadas nos campos certos. O Claude Code tem MCP nativo pro Pipedrive, então a integração foi descrita em linguagem natural: “quando o formulário for enviado, criar pessoa com nome e email, criar deal com título ‘Diagnóstico: [nome]’, mapear as respostas nos campos customizados X, Y e Z.” Levou 1,5 dia pra ficar funcionando sem bug. Testei com 8 submissões reais do time comercial pra validar o mapeamento de dados.

Semana 4: refinamentos, mobile e deploy final. Descobri que em telas menores que 375px o formulário quebrava em dois lugares. Ajustei via Claude Code, descrevendo o problema: “no iPhone SE o campo de texto do passo 3 está cortando no lado direito.” A IA encontrou o CSS responsável e corrigiu. Ajustei também o e-mail de confirmação automática que o lead recebe após o envio, refinei a página de agradecimento e fiz o deploy final com domínio customizado em mapeamento.expertintegrado.com.br.

O que a IA fez vs o que eu fiz?

Essa pergunta é mais importante do que parece, porque tem muita confusão no mercado sobre o que “construir com IA” significa de verdade.

A IA fez: estrutura de arquivos do projeto, componentes Astro, lógica de validação, integração com Pipedrive, CSS responsivo, lógica de envio de e-mail transacional, deploy automatizado via Vercel.

Eu fiz: spec completa do produto, decisões de UX (“o formulário deve ter 4 etapas, não 1 tela longa”), curadoria das perguntas do diagnóstico, revisão do tom de voz em cada texto, validação de negócio (“esse campo de orçamento precisa ter faixas, não valor aberto”), teste com usuários reais e priorização de bugs.

Tipo, a IA não tem ideia de qual pergunta de diagnóstico faz sentido pra qualificar um lead de automação. Isso é conhecimento de produto e de mercado. Ela sabe como transformar esse conhecimento em formulário funcional.

O que não funcionou e como corrigi?

Na semana 2, cometi o erro clássico de quem começa com Vibe Coding: pedi tudo de uma vez. Num único prompt pedi pra criar as seções do formulário, integrar validação, adicionar animação de transição entre etapas, configurar o hook de envio pro backend e ajustar o design da barra de progresso.

O código que saiu funcionava em partes. A animação quebrava a validação. O hook de envio não esperava a animação terminar. A barra de progresso atualizava no momento errado. Passei 4 horas tentando corrigir incrementalmente e fui cavando um buraco maior.

A solução foi resetar. Voltar pro último commit funcional, pegar a spec, dividir em 6 tarefas independentes e executar uma por vez, com commit entre cada uma. Depois disso nunca mais pedi mais de uma coisa por vez.

Outro ponto que não funcionou: confiei no primeiro design gerado sem questionar. Era funcional mas genérico, parecia qualquer SaaS de 2019. Precisei de uma rodada extra de refinamento de identidade visual, descrevendo o que eu queria em termos de sensação (“profissional mas não corporativo, direto mas não agressivo, cores que remetam a tecnologia aplicada em negócio real”). Levou um dia a mais que eu não tinha planejado.

Qual foi o resultado em taxa de conversão?

Nos 60 dias posteriores ao deploy, a taxa de proposta enviada após reunião de diagnóstico subiu de 70% para 84%. A taxa de conversão de proposta manteve os 40%. Isso significa que de cada 10 reuniões, a gente passou de 2,8 para 3,4 contratos fechados, um aumento de 21% sem mudar nada no processo comercial além da qualificação prévia.

A explicação é simples: leads que preencheram o formulário chegam na reunião com contexto já mapeado. O vendedor não perde 20 minutos fazendo perguntas básicas. A reunião começa no diagnóstico de verdade, não no cadastro de informações.

O custo total do projeto foi zero em desenvolvimento (assinatura de Claude Code que já tinha) mais R$0 de infraestrutura no mês (Vercel free tier suporta o volume que a gente tem). O ROI calculado em cima de um contrato médio de R$8.000 e do aumento de 0,6 contrato por 10 reuniões paga o projeto em 2 semanas de operação.

---

Perguntas frequentes

Preciso saber programar pra fazer isso? Não. Em nenhum momento do projeto eu escrevi JavaScript, HTML ou CSS manualmente. O que você precisa saber é descrever o que você quer com clareza. A especificação em linguagem natural é a habilidade central do Vibe Coding, e ela exige conhecimento de produto e de negócio, não de sintaxe de linguagem de programação. Vc já tem esse conhecimento. O que precisa aprender é como traduzir esse conhecimento em spec.

Quanto tempo leva pra aprender a trabalhar assim? Depende do projeto. Pra ferramentas internas simples como essa, 2 a 4 semanas de prática já entregam resultado real. O maior pulo de aprendizado não é técnico, é de mentalidade: parar de tentar controlar o código e começar a controlar a especificação. A maioria das pessoas trava nessa virada porque quer entender o que a IA está fazendo tecnicamente antes de confiar. Você não precisa entender o motor do carro pra dirigir.

Astro é a melhor opção pra esse tipo de projeto? Astro funcionou bem pra esse caso específico porque a ferramenta tem muito conteúdo estático com algumas ilhas de interatividade. Pra apps com mais estado compartilhado e lógica de frontend complexa, Next.js ou SvelteKit podem ser mais adequados. O Claude Code conhece todos esses frameworks, então a escolha é de produto, não de limitação de ferramenta.

E se eu tiver um projeto mais complexo do que um formulário? O princípio é o mesmo, a spec fica maior. Hoje uso a mesma abordagem pra funcionalidades do Expert Brain, pra integrações entre sistemas e pra automações internas. A chave é nunca perder o controle da spec. Quanto mais complexo o projeto, mais importante é dividir em unidades menores e iterar uma por vez. Projetos complexos construídos com Vibe Coding falham quando a spec vira uma lista de desejos sem prioridade.

Como integrei com o Pipedrive sem código? O Claude Code tem suporte a MCP (Model Context Protocol), que são conectores nativos com sistemas externos. O Pipedrive tem um MCP disponível. Com isso, descrevi em texto o que queria que acontecesse no Pipedrive quando o formulário fosse enviado, e o Claude Code usou o MCP pra gerar o código de integração e testar a conexão. Eu validei os dados no Pipedrive depois de cada teste, mas não escrevi uma linha de chamada de API manualmente.

Dá pra fazer isso com outras ferramentas além do Claude Code? Dá, mas com mais atrito. Cursor e Windsurf têm capacidade parecida, mas o suporte a MCP nativo é mais maduro no Claude Code hoje. O que realmente importa é ter uma ferramenta que permita alternar entre escrita de spec e execução de código no mesmo contexto, sem precisar copiar e colar entre janelas. Perder o contexto é o maior inimigo da produtividade no Vibe Coding.