Seu app feito com IA está pronto para produção?

Você construiu um produto com Lovable, Bolt, Replit, Cursor, Claude ou outra ferramenta de IA. Funcionou — talvez até melhor e mais rápido do que você esperava. Agora existem usuários de verdade, talvez os primeiros pagamentos, talvez dados que importam para outras pessoas além de você. Este texto é sobre a pergunta que costuma aparecer nesse momento: o que, exatamente, precisa ser revisado antes de ampliar o uso? Não é uma lista de medo, é um roteiro prático.

Funcionar não é o mesmo que estar pronto para produção

Um protótipo está pronto quando faz o que foi pedido, na hora em que foi testado, para quem estava testando — normalmente você mesmo. Produção é diferente: o sistema precisa continuar funcionando com pessoas que você não conhece, dados que não estavam lá durante os testes, e tentativas de uso que ninguém planejou, incluindo tentativas mal-intencionadas.

Isso não é uma crítica a ter usado IA para construir rápido. É reconhecer que validar uma ideia e sustentar um produto são dois problemas diferentes — e que a maioria das ferramentas de geração de código foi otimizada para o primeiro, não para o segundo.

O que muda quando entram usuários e dados reais

Enquanto só você usa o sistema, praticamente qualquer risco fica invisível — porque o volume é baixo e você é, ao mesmo tempo, o único usuário e alguém que confia no próprio código. Isso muda com usuários reais: uma falha de permissão deixa de ser teórica e vira exposição real de dados de outra pessoa; um erro não tratado deixa de ser um log ignorado e vira um cliente perdendo uma compra.

Autenticação não é o mesmo que autorização

Autenticação responde "quem é você" — login, senha, token. Autorização responde "o que você pode ver ou fazer", depois que o sistema já sabe quem você é. É comum um produto ter autenticação sólida (login funciona, senhas são protegidas) e autorização frágil (qualquer usuário autenticado consegue, por exemplo, acessar dados de qualquer outro, só trocando um número na URL ou em uma chamada de API).

Vale verificar explicitamente: cada tela, cada rota de API e cada consulta ao banco confirma que o usuário autenticado tem permissão sobre aquele dado específico — ou confia apenas que a interface não mostra o botão errado?

Permissões do banco e exposição de dados

Ferramentas como Supabase e Firebase facilitam muito começar rápido, mas colocam a responsabilidade de configurar regras de acesso (Row Level Security, regras de segurança do Firestore, etc.) diretamente nas mãos de quem constrói. Sem essa configuração — ou com ela mal ajustada —, qualquer cliente com a chave pública da API consegue, em teoria, ler ou escrever dados que não deveria.

Segredos e variáveis de ambiente

Chaves de API, tokens e credenciais de banco de dados nunca deveriam aparecer no código enviado ao navegador, nem em um repositório público. É um erro fácil de cometer quando se está movendo rápido — copiar uma chave direto no código "só para testar" e esquecer de mover para uma variável de ambiente depois. Vale uma checagem simples: abra o código-fonte que chega ao navegador (o que o usuário final consegue inspecionar) e procure por chaves, tokens ou senhas visíveis.

Separação entre desenvolvimento e produção

Testar uma mudança arriscada direto no banco de dados real, com dados de clientes reais, é uma das formas mais comuns de um erro pequeno virar um incidente grande. Ter ambientes separados — um banco de dados e uma URL só para desenvolvimento, outro para produção — custa pouco para configurar e evita que um teste vire um problema para quem já está usando o produto.

Backups e restauração

Ter backup automático configurado é diferente de saber que ele funciona. A única forma de ter certeza é testar uma restauração, pelo menos uma vez, em um ambiente que não seja o de produção. Times descobrem que o backup nunca funcionou justamente no momento em que mais precisam dele — e nesse momento já é tarde.

Logs, monitoramento e alertas

Sem monitoramento, a forma como você descobre que algo quebrou é um usuário reclamando — ou, pior, um usuário simplesmente indo embora sem reclamar. Um alerta básico quando erros importantes acontecem (mesmo que seja só um e-mail ou uma notificação) já reduz bastante o tempo entre "algo quebrou" e "alguém percebeu".

Testes dos fluxos críticos

Não é preciso cobrir cada linha de código com testes automatizados. Vale identificar os dois ou três fluxos que, se quebrarem, causam o maior problema — geralmente login, pagamento e qualquer ação que grava dados importantes — e garantir que existe alguma forma confiável de verificar que eles continuam funcionando depois de cada mudança.

Deploy e rollback

Publicar uma mudança deveria ser um processo repetível, não uma sequência de passos manuais que só uma pessoa lembra de cor. E, quando uma publicação causa problema, deveria existir uma forma conhecida e testada de reverter — sem precisar reconstruir tudo do zero sob pressão.

Pagamentos, webhooks e duplicidade

Sistemas de pagamento enviam eventos (webhooks) que podem, por razões da própria infraestrutura do provedor, chegar mais de uma vez para o mesmo evento. Se o sistema não tiver proteção contra processamento duplicado, isso pode significar cobrar um cliente duas vezes ou liberar um produto sem pagamento correspondente. É um dos pontos onde vale mais atenção antes de ampliar o uso.

Como saber se vale continuar, refatorar ou reconstruir

A resposta raramente é binária. Diante de um sistema criado rapidamente, geralmente existem cinco caminhos possíveis para cada parte dele: manter como está, proteger com controles adicionais, refatorar uma seção específica, substituir um componente pontual, ou reconstruir. Reconstruir é o caminho mais caro e o mais oferecido por quem ainda não investigou o que de fato existe — vale a pena desconfiar dessa recomendação quando ela chega cedo demais.

• Mapeie o que já funciona bem e não precisa de intervenção.
• Separe riscos de segurança e dados (prioridade alta) de melhorias de conveniência (prioridade baixa).
• Pergunte: essa parte específica está causando problema recorrente, ou só parece desorganizada?
• Considere o custo de parar o produto para reconstruir versus o custo de proteger e evoluir aos poucos.

Quando chamar um engenheiro

Alguns sinais tornam essa conversa mais urgente: o produto está prestes a receber pagamentos ou dados sensíveis; a IA já tentou corrigir o mesmo problema mais de uma vez sem sucesso; ninguém tem certeza se os dados estão protegidos; uma alteração pequena quebrou algo sem relação aparente; ou existe a sensação de que qualquer mudança agora é arriscada.