Checklist de lançamento para apps construídos com IA: 5 verificações

Um bom checklist de lançamento para um app construído com IA se resume a quatro verificações antes de os usuários reais chegarem: quem pode ler quais dados, quais chaves estão expostas no navegador, se os pagamentos são confirmados no servidor e se você consegue restaurar um backup. Mais duas etapas, um teste de carga básico e um rollout gradual, deixam o lançamento tranquilo.

Sou engenheiro sênior brasileiro, e esta é a ordem em que faço essas verificações quando analiso um app gerado pelo Lovable, Bolt, Base44 ou ferramentas parecidas. Nada disso exige uma auditoria completa. Algumas verificações bem focadas encontram a maior parte do risco, e corrigir problemas fica mais caro depois que usuários reais e pagamentos estão no sistema.

O que precisa ser verdade antes de lançar um app construído com IA?

Antes do lançamento, cinco afirmações devem ser verdadeiras, e você deve conseguir provar cada uma delas, não apenas acreditar nelas:

1. Um usuário não consegue ler nem alterar os dados de outro usuário.
2. Nenhuma chave secreta vai para o navegador.
3. Um pedido só é marcado como pago depois que o servidor confirma o pagamento.
4. Você já restaurou um backup pelo menos uma vez, com sucesso.
5. O app funciona com mais de uma pessoa usando ao mesmo tempo.

A lista é curta por causa do modelo de responsabilidade compartilhada. O construtor e o provedor de banco de dados protegem os servidores e as contas deles. Eles não sabem quais são as suas regras de negócio. Quem pode ver uma fatura, qual preço é válido, quando um pedido conta como pago: isso é comportamento do seu app, então cabe a você verificar.

Ferramentas de IA são boas em fazer telas funcionarem. São mais fracas nas partes invisíveis, e são exatamente essas partes que as verificações abaixo cobrem.

As regras de acesso a dados foram testadas com uma segunda conta?

Esta é a verificação que eu nunca pularia. Se o seu app usa Supabase, o acesso é controlado por políticas de row level security (RLS). Apps construídos com o Lovable já mostraram um padrão de regras de RLS fracas, então não presuma que as suas estão certas só porque o app parece funcionar bem quando você usa.

Como testar em 15 minutos

1. Crie duas contas de usuário comuns, A e B, em navegadores separados.
2. Como A, crie um registro: um pedido, um documento, uma anotação no perfil.
3. Como B, tente abrir o registro de A pela URL ou pelo ID. Deve falhar.
4. Abra as ferramentas de desenvolvedor do navegador como B, encontre a requisição de API que o app faz e troque o ID ou o filtro pelo de A. Não deve retornar nada.
5. Saia da conta completamente e repita a requisição. O acesso anônimo deve ser recusado para qualquer coisa privada.

Verifique também se o RLS está realmente habilitado em todas as tabelas, não só nas que você lembra. Uma tabela sem RLS, com a chave pública no navegador, pode ser lida por qualquer pessoa que procurar. Preste atenção em políticas que dizem algo como “permitir se o usuário estiver logado” sem vincular a linha a esse usuário.

O caso do Base44 de julho de 2025 é um lembrete útil. Pesquisadores da Wiz descobriram que alguém conseguia se cadastrar em apps que deveriam ser privados usando apenas o ID do app, e isso foi corrigido em um dia. A plataforma corrigiu a parte dela rapidamente, mas a lição para os donos é confirmar, de fora, que o seu app privado é realmente privado.

Alguma chave está exposta no navegador?

Tudo o que chega ao navegador é público. Abra o site, veja o JavaScript carregado pela página e a aba de rede, e observe o que é enviado.

Algumas chaves foram feitas para ser públicas: a anon key do Supabase, a publishable key do Stripe. Elas só são seguras se as suas regras de dados estiverem corretas, e é por isso que a verificação anterior vem primeiro. Outras chaves nunca devem aparecer ali:

• Service role key do Supabase (ela ignora o RLS por completo)
• Secret key do Stripe e o segredo de assinatura do webhook
• Qualquer chave de API de terceiros que cobra por chamada, como um provedor de modelos de IA ou um serviço de email

O que fazer se encontrar uma

Primeiro rotacione a chave, depois corrija o código. Remover uma chave do código não adianta se ela já foi servida a visitantes ou commitada em um repositório, porque ela deve ser tratada como vazada. Mova a chamada que precisa dela para uma função no servidor ou uma rota de backend, e mantenha o segredo em variáveis de ambiente do lado do servidor.

Se o código está no GitHub, pesquise também o histórico do repositório. Uma chave apagada na semana passada continua nos commits antigos.

O pagamento é confirmado no servidor?

Um padrão comum em código gerado por IA é redirecionar o usuário para o Stripe Checkout e, quando ele volta para uma página de “sucesso”, marcar o pedido como pago. Essa página pode ser acessada por qualquer pessoa que adivinhe a URL, e é pulada por completo se o usuário fechar a aba depois de pagar.

A abordagem confiável é o Stripe notificar o seu servidor por um webhook, e o seu servidor verificar a assinatura do evento antes de alterar qualquer coisa. Só então o pedido deve passar a constar como pago.

Teste estes casos:

• Abra a URL de sucesso diretamente, sem pagar. O pedido deve continuar não pago.
• Pague e feche a aba antes do redirecionamento. O pedido ainda deve ficar como pago.
• Reenvie o mesmo evento de webhook duas vezes. Você não deve ficar com dois pedidos nem duas entregas.
• Verifique se o valor e o produto vêm do seu servidor, e não de valores enviados pelo navegador. Um usuário não deve conseguir editar um preço em uma requisição.

É aqui que scanners de segurança genéricos costumam falhar, porque pedidos duplicados e lógica de webhook são lógica de negócio, não padrões de vulnerabilidade conhecidos. Os detalhes de webhooks merecem um passo a passo próprio, então aqui trato só da questão no nível do lançamento: quem decide é o servidor ou o navegador?

Você consegue restaurar um backup?

Ter backups habilitados não é o mesmo que ter um backup que você consegue restaurar. Muitos fundadores descobrem a diferença durante um incidente.

Faça um simulado antes do lançamento:

1. Descubra o que o plano do seu banco de dados realmente inclui no backup e com que frequência. Consulte a documentação atual do provedor, porque isso varia conforme o plano.
2. Restaure um backup em um projeto separado e vazio.
3. Abra a cópia restaurada e confira se os dados recentes estão lá e se o app consegue se conectar a ela.
4. Anote os passos e quanto tempo levou.

Decida também onde o seu código fica. Código construído no Lovable pode ser levado para o GitHub e para a sua própria hospedagem, o que dá a você uma cópia sob o seu controle. Se a conta no construtor fosse suspensa amanhã, você ainda conseguiria fazer deploy? Se a resposta for não, resolva isso antes do lançamento. Arquivos enviados, como imagens e documentos, muitas vezes ficam armazenados separados do banco de dados, então confirme que eles também estão cobertos.

O app vai aguentar tráfego real?

Você não precisa de um teste de carga grande. Precisa encontrar as falhas óbvias. Usuários reais fazem coisas que a sua demo nunca fez: abrem várias abas, atualizam a página sem parar e chegam todos no mesmo momento depois que você manda um email.

Verificações simples que encontram a maior parte dos problemas:

• Use uma ferramenta de carga gratuita para simular algumas dezenas de usuários simultâneos nos fluxos principais: cadastro, login, a página de listagem principal e o checkout.
• Fique de olho no banco de dados. Páginas que carregam todas as linhas de uma tabela e filtram no navegador ficam lentas conforme os dados crescem.
• Procure índices faltando em colunas pelas quais você filtra ou ordena.
• Verifique limites de requisições no login, na redefinição de senha e em qualquer endpoint que envie email ou chame uma API paga. Sem limites, um único script pode inflar a sua conta.
• Confirme os limites do plano da sua hospedagem e do seu banco de dados. Planos gratuitos muitas vezes pausam ou limitam o uso.

Configure também rastreamento de erros e um monitoramento básico de disponibilidade. Se algo quebrar às 2 da manhã, você quer ficar sabendo por um alerta, não por um cliente.

Como liberar para os primeiros usuários com segurança?

Lance em etapas. Um grupo pequeno expõe os problemas enquanto o estrago ainda é pequeno.

1. Ambientes separados. Mantenha dados de teste e dados reais separados, e use o modo de teste do Stripe até o fim.
2. Convide um grupo pequeno. Comece com um grupo pequeno de pessoas com quem você consegue falar diretamente; como regra prática, no máximo algumas dezenas.
3. Acompanhe os primeiros pagamentos manualmente. Compare cada pagamento no Stripe com o pedido correspondente no seu banco de dados.
4. Tenha um rollback. Saiba como voltar rapidamente para a versão anterior e quem faz isso.
5. Amplie aos poucos. Só expanda depois de alguns dias sem surpresas.

Continuar no construtor às vezes é a decisão certa, principalmente para uma ferramenta interna ou um app pequeno com dados de baixo risco. As verificações acima valem de qualquer forma. E se uma verificação falhar, corrija primeiro o problema específico no código existente. Uma reescrita raramente é o primeiro passo.

Quer uma segunda opinião?

Se você está prestes a lançar um app construído com IA, mande um email para me@filipeeduardo.dev com o link e uma descrição curta, e eu conto com prazer o que eu verificaria primeiro.