Seu app do Lovable ou Bolt travou na hora de integrar? O que fazer

Recebo cada vez mais gente que chega com um app funcionando: tela bonita, fluxo definido, protótipo que rodou em dias com Lovable, Bolt, v0 ou ferramenta parecida. E chega justamente porque, num certo ponto, o app parou de andar.

Não é falha da ferramenta. É uma fronteira previsível, e vale entender onde ela fica antes de continuar construindo em cima dela.

O vibe coding resolve um problema real

Gerar interface, fluxo de tela e lógica simples de front-end a partir de um prompt é rápido de um jeito que não era há alguns anos. Pra validar uma ideia, mostrar um protótipo pra um sócio ou testar um conceito com usuário real antes de contratar um time inteiro, isso tem valor de verdade. Não é enrolação, é ferramenta certa pro trabalho certo.

Onde ele trava (quase sempre no mesmo lugar)

Na prática, o travamento aparece num punhado de pontos recorrentes:

• Autenticação de verdade: sessão, permissão, controle de quem pode ver o quê.
• Dado real, não mock: puxar informação de um banco de produção, não de um exemplo fixo no código.
• Integração com sistema externo: falar com uma API de pagamento, de ERP, de CRM ou de qualquer serviço de terceiro, com autenticação, tratamento de erro e log.
• Regra de negócio específica: a exceção que só existe na sua operação, e que nenhum prompt genérico previu.

Reparei que quase sempre é o mesmo padrão: a tela existe, o dado de verdade e a integração externa é que faltam.

Por que isso acontece

Essas ferramentas foram otimizadas pra gerar interface e fluxo a partir de descrição em linguagem natural. Isso é diferente de arquitetar uma integração: entender o contrato de uma API externa, decidir o que fazer quando ela falha, guardar credencial com segurança, versionar schema de banco. É um tipo de trabalho mais parecido com engenharia do que com geração de tela, e a maioria das ferramentas de vibe coding não foi desenhada pra essa parte.

Isso não é defeito. É só um limite de escopo que vale conhecer antes de prometer prazo pra alguém.

O que eu faço quando entro num projeto travado

Primeiro, eu leio o código gerado inteiro antes de mexer em qualquer coisa. Boa parte do trabalho já está feito, e jogar tudo fora pra recomeçar do zero costuma ser desperdício. Depois eu identifico exatamente onde o fluxo emperra: geralmente é uma chamada de API que não existe, uma variável de ambiente que nunca foi configurada, ou uma tabela que só tem dado de exemplo.

A partir daí, entro com o que falta: autenticação real, conexão com o sistema externo (via API, com tratamento de erro e log de execução), e ajuste da regra de negócio que o protótipo simplificou demais. O objetivo não é reescrever o app, é terminar a ponte que ele não tinha condição de construir sozinho.

Como saber se o seu app está pronto pra virar produto de verdade

Antes de assumir que “só falta lançar”, vale checar:

• O app puxa dado de um banco de produção, ou ainda mostra exemplo fixo?
• Existe controle de quem acessa o quê, ou qualquer um vê qualquer coisa?
• As integrações externas (pagamento, e-mail, CRM, ERP) estão realmente conectadas, ou só têm um botão que não faz nada?
• Se uma chamada de API falhar, o app avisa alguém, ou trava em silêncio?

Se a resposta pra alguma dessas for “não sei” ou “acho que não”, ainda falta a parte de integração de verdade.

Conclusão

Vibe coding é uma ferramenta boa pra validar ideia rápido. O problema aparece quando alguém tenta pular direto do protótipo pro produto em produção sem passar pela parte que a ferramenta não resolve sozinha: dado real, integração externa, autenticação e regra de negócio. Essa parte não precisa ser recomeçada do zero, precisa de alguém que entre no código, entenda o que já existe e termine o que falta.

Seu app travou exatamente nesse ponto? Fale comigo.