Apps de construtores com IA: o que corrigir antes dos usuários reais

Um construtor de apps com IA como Lovable, Bolt ou Base44 pode entregar um app funcionando em uma tarde. O que ele não entrega é a prova de que o app é seguro para usuários reais e pagamentos reais. A maior parte do risco está em quatro lugares: quem pode ler quais dados, quais chaves estão expostas, como os pagamentos são confirmados e se você consegue restaurar um backup.

Sou engenheiro full-stack sênior brasileiro, com sete anos de experiência (desde 2019) construindo produtos web e mobile de ponta a ponta. Este guia é o que eu verificaria primeiro em um app que outra pessoa gerou. Você não precisa de uma auditoria completa para encontrar a maioria dos problemas, mas precisa olhar antes do lançamento, porque corrigir as coisas fica mais caro quando já existem usuários e pagamentos reais.

O que um construtor de apps com IA realmente constrói para você?

Um construtor típico gera um frontend (muitas vezes em React), conecta esse frontend a um serviço de backend (com muita frequência o Supabase, para banco de dados e login), integra pagamentos (muitas vezes o Stripe) e hospeda o resultado. Você descreve as funcionalidades em linguagem comum e ele escreve o código.

Isso é realmente útil para protótipos, ferramentas internas e validação inicial. O resultado geralmente parece pronto: as páginas carregam, os formulários salvam, o login funciona. A lacuna está no que você não vê clicando pelo app:

• Regras sobre qual usuário pode ler ou alterar quais linhas.
• Onde ficam os segredos e se eles vão parar no navegador.
• O que acontece quando um evento de pagamento chega duas vezes, atrasado ou nunca.
• O que acontece quando o banco de dados é corrompido ou apagado.

O construtor otimiza para um app que funciona na demo. Produção pergunta o que acontece quando alguém age de má-fé, quando o tráfego cresce ou quando algo falha no meio do caminho. Por isso chamo o código gerado de primeiro rascunho: um bom ponto de partida, mas não revisado por alguém que estivesse pensando em falhas.

O que o construtor protege e o que continua sendo responsabilidade sua?

Aqui a segurança é uma responsabilidade compartilhada. O construtor protege a própria infraestrutura e as contas. Você, como dono do app, é responsável pelo comportamento do seu app: quem pode ler quais dados, o que acaba no navegador, como os pagamentos são confirmados e se existem backups.

Um exemplo público mostra por que essa divisão importa. Em julho de 2025, pesquisadores da Wiz descobriram que o Base44, o construtor de apps com IA da Wix, permitia que um atacante se cadastrasse em apps que deveriam ser privados usando apenas o ID do app. Foi corrigido em um dia. Era um problema do lado da plataforma, e a plataforma corrigiu. Mas isso também mostra que você não pode presumir que toda configuração é segura por padrão, e que apps privados são tão privados quanto as camadas ao redor deles.

Do outro lado, uma regra de dados fraca no seu próprio projeto Supabase não é bug da plataforma. É configuração sua, e ninguém vai corrigir se você não verificar. Não estou dizendo que essas ferramentas são ruins. Estou dizendo que a linha de responsabilidade é clara, e a maioria dos fundadores não sabe de que lado dela está.

Quais quatro verificações cobrem a maior parte do risco antes do lançamento?

Você não precisa de uma auditoria de um mês. Na minha experiência, quatro verificações focadas pegam a maior parte do que importa antes da chegada dos usuários reais:

1. Regras de acesso a dados: um usuário consegue ler ou editar os dados de outro usuário?
2. Chaves expostas: algum segredo está visível no navegador ou no repositório?
3. Confirmação de pagamento: o app libera acesso só depois que o provedor de pagamento confirma, e lida com repetições?
4. Backups: você consegue restaurar seus dados, e já testou?

Na minha experiência, cada uma leva horas, não semanas, se você sabe onde olhar, embora isso varie de app para app. As próximas quatro seções passam por cada uma delas. Esta é a minha regra prática, não um padrão formal, e não substitui uma auditoria de verdade para apps que lidam com dados muito sensíveis, como registros de saúde ou financeiros.

Quem pode ler quais dados no meu app construído com IA?

Esta é a verificação que faço primeiro. Com o Supabase, o navegador fala direto com o banco de dados, e a row level security (RLS) decide o que cada usuário logado pode ver. Se a RLS estiver desligada, ou se as regras forem permissivas demais, qualquer pessoa que tenha a URL pública do seu projeto e a chave consegue consultar as tabelas. Apps construídos com Lovable têm mostrado um padrão de regras de RLS fracas, então é aqui que eu olho antes de qualquer outra coisa.

O que testar

• Abra o painel do Supabase e liste todas as tabelas. Confirme que a RLS está habilitada em cada uma.
• Leia cada policy. Uma regra que diz que qualquer pessoa pode fazer select, insert ou update geralmente é resto do desenvolvimento.
• Crie duas contas de teste. Faça login como usuário A, copie o ID de um registro do usuário B e tente ler ou alterar esse registro.
• Teste deslogado. O acesso anônimo deve se limitar ao que é realmente público.
• Verifique os buckets de storage. Confirme se os arquivos enviados são públicos ou privados, já que um bucket pode ser configurado como público.

Erros comuns

Policies que verificam só se o usuário está logado, e não se a linha pertence a ele. Funcionalidades de admin protegidas apenas escondendo um botão na interface. Tabelas com dados pessoais legíveis por qualquer conta. A correção geralmente é um punhado de policies escritas com cuidado, não uma reconstrução. Peça para a IA do construtor escrevê-las se quiser, mas confirme com o teste das duas contas, porque essa é a prova que importa.

Alguma chave secreta está exposta no navegador?

Tudo que vai para o navegador é público. Qualquer pessoa pode abrir as ferramentas de desenvolvedor e ler. Algumas chaves foram feitas para isso, como a anon key do Supabase (segura só se a RLS estiver correta) e a publishable key do Stripe. Outras nunca podem sair do servidor: a service role key do Supabase, as chaves secretas do Stripe, os segredos de webhook e as chaves de API de terceiros para email, modelos de IA ou SMS.

Como procurar

• Abra seu app no ar, veja o código-fonte da página e a aba de rede, e procure palavras como secret, key, token e service_role.
• Procure no seu repositório de código, incluindo o histórico, pelos mesmos termos e por arquivos .env.
• Verifique qualquer chamada feita direto do frontend para uma API paga. Se a chave está no navegador, alguém pode usá-la na sua conta.

O que fazer se encontrar uma

Primeiro, rotacione a chave, ou seja, gere uma nova e revogue a antiga. Tirar a chave do código não basta, porque ela pode já ter sido copiada. Depois, mova a chamada para uma função de servidor ou para o backend, onde a chave fica como variável de ambiente e o navegador só chama o seu endpoint. Esse endpoint também deve verificar quem está pedindo e limitar o uso.

Meu app confirma os pagamentos corretamente?

É aqui que os scanners genéricos falham, porque se trata de lógica de negócio. Um padrão comum em código gerado: depois que o cliente volta da página de checkout do Stripe, o app marca o pedido como pago com base no redirecionamento. Mas um redirecionamento não prova nada. Alguém pode acessar a URL de sucesso diretamente, ou o cliente pode pagar e fechar a aba antes de voltar.

A abordagem confiável é que o seu servidor receba eventos do Stripe (webhooks), verifique a assinatura deles com o segredo do webhook e só então libere o acesso ou marque o pedido como pago.

O que verificar

• Existe um endpoint de webhook, e ele verifica a assinatura?
• O acesso é liberado só a partir de eventos verificados, e não pela página de sucesso?
• O handler é idempotente? O Stripe pode enviar o mesmo evento mais de uma vez, e você não pode criar dois pedidos nem creditar duas vezes.
• O que acontece com pagamentos recusados, reembolsos, disputas e assinaturas canceladas?
• Um usuário consegue mudar o preço ou o plano em uma requisição feita pelo navegador?

Teste com o modo de teste do Stripe antes de cobrar qualquer cartão real. Não vou me aprofundar em webhooks aqui, porque eles merecem um passo a passo próprio, mas se você for verificar só um item de pagamento, que seja este: nunca confie no navegador para dizer que um pagamento deu certo.

Tenho backups que consigo de fato restaurar?

Um backup que você nunca restaurou é uma esperança, não um backup. Apps gerados muitas vezes rodam em um único banco de dados com as configurações padrão, e os fundadores presumem que outra pessoa está cuidando disso. Na divisão de responsabilidade compartilhada, confirmar os backups é trabalho seu.

Perguntas para responder

• O plano do seu banco de dados inclui backups automáticos, e até quanto tempo atrás eles vão?
• A recuperação point-in-time está disponível no seu plano, ou só snapshots diários?
• Os arquivos enviados também entram no backup, ou só o banco de dados?
• Você tem uma cópia do seu código fora do construtor?
• Alguém já restaurou um backup em um projeto de teste separado e confirmou que o app funciona com ele?

Pense também em acidentes, não só em ataques. Uma migração gerada ou uma edição da IA pode apagar uma coluna ou sobrescrever dados. Um teste de restauração costuma ser um exercício curto (minha estimativa: umas duas horas para um app pequeno) e mostra quanto tempo a recuperação levaria. Confira os recursos de backup atuais do seu plano na documentação do provedor, já que eles mudam com o tempo e variam por nível.

Devo corrigir o código gerado por IA ou reescrevê-lo?

Corrija primeiro. Trate o código gerado como um primeiro rascunho e corrija os problemas de maior risco no código existente antes de considerar uma reescrita. Reescritas parecem limpas, mas jogam fora telas, fluxos e decisões que funcionam, e atrasam o lançamento enquanto introduzem novos bugs.

A ordem que eu usaria:

1. Feche as regras de dados e rotacione as chaves expostas.
2. Corrija a confirmação de pagamento e torne os handlers idempotentes.
3. Configure backups e teste uma restauração.
4. Leve o código para o GitHub, adicione monitoramento básico de erros e uma cópia de staging.
5. Depois, organize a estrutura onde ela dói: lógica duplicada, arquivos gigantes, queries lentas.

Uma reescrita passa a fazer sentido quando o modelo de dados está fundamentalmente errado, quando toda mudança quebra outra coisa ou quando você precisa de recursos que a estrutura gerada não suporta. Mesmo assim, eu aproveitaria o que funciona, como o schema e as telas, em vez de começar do zero. Pedir para o construtor corrigir os próprios problemas de segurança ajuda nas coisas simples, mas regras de dados, chaves e fluxos de pagamento são justamente o que essas ferramentas costumam errar, então confira as respostas você mesmo ou com um segundo par de olhos.

Quando continuar no construtor de apps com IA é a melhor decisão?

Sair nem sempre é a resposta. Ficar costuma ser melhor quando:

• O app é um protótipo ou uma ferramenta interna com poucos usuários de confiança.
• Você ainda está validando a ideia e o design muda toda semana.
• Não há pagamentos e há poucos dados sensíveis.
• Ninguém no time conseguiria manter uma base de código e uma hospedagem separadas.
• As quatro verificações passam e os limites do construtor não estão travando você.

Migrar tem custos reais: você assume hospedagem, deploys, variáveis de ambiente e monitoramento. Se ninguém consegue cuidar disso, você pode estar trocando um risco administrável por um novo.

Sinais de que é hora de sair: você precisa de lógica de backend customizada e o construtor fica no seu caminho, você precisa de ambientes e revisão de código, o preço ou os limites não servem mais, o desempenho sofre com tráfego real, ou um cliente exige controle sobre onde o app roda. A decisão deve vir de um bloqueio concreto, não de uma sensação vaga de que empresas de verdade usam hospedagem própria.

Como levo meu código para o GitHub e para a minha própria hospedagem?

Código construído no Lovable pode ser levado para o GitHub e para a hospedagem do próprio dono. Outros construtores têm suas próprias opções de exportação, então verifique o que o seu suporta antes de planejar.

1. Conecte o projeto ao GitHub usando a integração do construtor, para que o repositório passe a ser a fonte da verdade.
2. Clone e rode localmente. Corrija o que só funcionava dentro do construtor.
3. Liste as variáveis de ambiente e guarde-as nas configurações da sua hospedagem, nunca no repositório.
4. Seja dono das contas de backend. Garanta que as contas do Supabase e do Stripe pertençam a você ou à sua empresa, e não ao login pessoal de um ex-prestador de serviço.
5. Escolha a hospedagem. Um frontend estático ou em Next.js funciona em plataformas comuns como Vercel ou Netlify, enquanto o código de servidor pode rodar como funções ou em um servidor pequeno.
6. Configure uma cópia de staging com chaves de teste, faça o deploy lá primeiro e teste login, regras de dados e pagamentos.
7. Troque o domínio só depois que o staging passar, e mantenha a versão antiga rodando até ter certeza.

Faça isso antes do lançamento, se puder. Migrar um app no ar com usuários pagantes significa migrar dados e evitar sessões quebradas, o que é possível, mas exige mais cuidado. Não prometo nada sobre downtime em nenhuma migração, mas um ensaio em staging reduz muito as surpresas.

Quer uma segunda opinião sobre o seu app?

Se você construiu algo com uma ferramenta de IA e não tem certeza sobre uma dessas quatro verificações, mande um email para me@filipeeduardo.dev com o link e algumas linhas sobre o que o app faz, e eu digo o que verificaria primeiro.