É uma das frases mais antigas do desenvolvimento de software, e os apps feitos com IA a trouxeram de volta com força: “na minha máquina funciona”. Na prévia da ferramenta está tudo certo; publicado no domínio de verdade, a tela fica branca, o login não entra ou os dados não aparecem.
Quase sempre a causa é uma destas cinco.
1. Variáveis de ambiente que não foram para o servidor
O app depende de configurações que não estão no código: endereço do banco, chaves de serviços, URL do próprio site. Na prévia, a ferramenta preenche isso sozinha. No servidor novo, alguém precisa cadastrar cada uma.
Como identificar: erros falando em undefined, “invalid API key” ou chamadas indo para localhost.
Como evitar: mantenha uma lista (um arquivo .env.example, sem os valores) com todas as variáveis que o app precisa, e confira essa lista a cada publicação.
2. Banco de dados diferente do que você testou
Na prévia, o app pode estar usando um banco de teste, com tabelas criadas na mão ao longo da conversa com a IA. Em produção, o banco não tem as mesmas tabelas, colunas ou regras de acesso.
Como identificar: erros de “relation does not exist”, “column not found”, ou telas vazias que deveriam ter dados.
Como evitar: toda mudança no banco deve virar uma migration, um arquivo versionado que descreve a alteração. Assim, o banco de produção é montado pelos mesmos passos do banco de teste, sem depender de memória.
3. Dependências sem versão fixa
O projeto diz que precisa de uma biblioteca, mas não diz qual versão. Na prévia, foi instalada uma; no servidor, meses depois, vem outra, com comportamento diferente.
Como identificar: erros dentro de bibliotecas que você nunca tocou, ou que aparecem “do nada” sem mudança no seu código.
Como evitar: mantenha o arquivo de travamento de versões (package-lock.json, pnpm-lock.yaml, yarn.lock) no repositório e use a mesma versão do Node em todo lugar.
4. O build de produção nunca foi testado
A prévia roda em modo de desenvolvimento, que tolera muita coisa. O build de produção é mais rigoroso: erros de tipo, importações quebradas e variáveis ausentes que passavam despercebidos param a publicação.
Como identificar: a publicação falha, ou publica mas algumas páginas quebram.
Como evitar: rode o build de produção (npm run build, por exemplo) antes de publicar, de preferência automaticamente a cada mudança.
5. Domínio, HTTPS e redirecionamentos
O login com Google, os links de confirmação de e-mail e as chamadas entre front-end e back-end dependem do endereço do site. Se o app foi configurado com o endereço da prévia, ao mudar para o domínio próprio tudo que depende dele quebra.
Como identificar: login social que volta para a prévia, e-mails com link errado, erros de CORS no console do navegador.
Como evitar: cadastre o domínio de produção nos serviços de autenticação, nas URLs de retorno e nas variáveis do app antes de virar a chave.
O que resolve de vez: um caminho de publicação
Os cinco problemas têm a mesma raiz: a publicação depende de passos manuais que ninguém escreveu. O que resolve é ter um caminho repetível:
- Código num repositório, com histórico.
- Um ambiente de teste (staging) igual ao de produção, com dados de teste.
- Publicação automática a partir do repositório, que roda o build e para se algo falhar.
- Uma forma rápida de voltar à versão anterior.
Parece burocracia para um app pequeno, mas é o contrário: é o que permite corrigir e publicar várias vezes por dia sem medo.
Escrito pela equipe da Grimpo com apoio de inteligência artificial e revisado por uma pessoa. Viu um erro ou quer sugerir um tema? Fale com a gente.
Perguntas frequentes
Por que a prévia da ferramenta funciona e o site publicado não?
A prévia roda num ambiente controlado pela ferramenta, com configurações que ela preenche sozinha. Ao publicar em outro lugar, essas configurações (chaves, endereços, versão do Node, banco) precisam ser recriadas, e normalmente é aí que algo fica faltando.
O que é um ambiente de staging?
É uma cópia do ambiente de produção usada para testar antes de publicar. Tem a mesma configuração, mas com dados de teste. É o lugar para descobrir o problema antes do cliente.
Fontes
Continue lendo
Criei um app com IA. Ele está pronto para ir ao ar?
Funcionar na sua tela não é o mesmo que aguentar cliente de verdade. Doze perguntas para responder antes de publicar um app…
Chave de API no código: o erro que mais custa caro em app feito com IA
Por que a IA coloca a chave dentro do código, como descobrir se a sua está exposta e o que fazer nos…
Supabase e Firebase sem regras de acesso: quando qualquer usuário lê o banco inteiro
O banco que a IA escolheu deixa o navegador falar direto com os dados. Sem as regras certas, um usuário vê os…