# Como levar um app do Lovable, Bolt ou v0 para produção Canonical URL: https://thorfyn.com/pt/notes/app-do-lovable-bolt-v0-para-producao > O que quebra quando um app feito com IA encontra usuários reais, a ordem de consertar e como saber quando reconstruir sai mais barato que endurecer. Resposta curta: leve o código para um repositório seu, feche as brechas de segurança, separe staging de produção, tenha como ver erros e restaurar dados, e só então decida entre endurecer o que existe ou reconstruir por estágios. - Método da casa - Escrito por Matheus Pavaneli (https://thorfyn.com/pt/about) - Publicado em 10 de out. de 2026 - Revisado em 10 de out. de 2026 - 3 min ## O que quebra quando chegam usuários de verdade Um app gerado é feito para mostrar a ideia. Usuários de verdade trazem o que ele pulou: regras de dados, pagamento que não pode rodar duas vezes, e-mail que precisa chegar e uma conta que cresce a cada requisição. Nada disso aparece na demonstração, tudo aparece no primeiro mês. ## Leve o código para um repositório seu Enquanto o código vive só dentro da ferramenta, ninguém mais consegue revisar, testar ou publicar sem ela. - **Confira você mesmo** — Confira se o projeto está ligado a um repositório do GitHub na sua própria conta, não numa conta compartilhada. - **Corrija** — Exporte ou sincronize o projeto com um repositório no seu nome e faça toda mudança seguinte passar por ele. ## Feche as brechas de segurança primeiro Tabelas expostas e chaves vazadas são as falhas que mais custam e que chegam primeiro. - **Confira você mesmo** — Faça as quatro checagens do Supabase do guia sobre vazamento: RLS, a chave service_role, os redirecionamentos e o staging. - **Corrija** — Corrija o RLS e a service_role antes de tudo; são eles que decidem quem lê os dados dos seus usuários. ## Separe staging de produção Toda mudança testada em produção arrisca dados reais, e todo segredo no código vai para o navegador. - **Confira você mesmo** — Liste para onde cada ambiente aponta: banco, chaves de pagamento, remetente de e-mail. Se staging e produção dividem algum, não estão separados. - **Corrija** — Crie um projeto de staging, guarde os segredos em variáveis de ambiente de cada um e publique em staging antes da produção. ## Veja os erros e saiba restaurar os dados Sem rastreio de erros você descobre as falhas pelos clientes, e sem backup testado uma mudança ruim é para sempre. - **Confira você mesmo** — Responda duas perguntas: onde eu veria um erro que um usuário teve há uma hora, e quando restaurei um backup numa cópia pela última vez? - **Corrija** — Ligue o rastreio de erros e o backup do banco, e restaure um backup numa cópia uma vez, para saber que funciona. ## Endurecer ou reconstruir Endureça quando o modelo de dados serve ao produto e a maioria das telas só precisa de conserto. Reconstrua por estágios quando cada recurso novo quebra um antigo, quando o modelo de dados briga com o produto ou quando os limites da ferramenta travam o que os usuários pedem. Nos dois casos o trabalho vai um estágio por vez, com o app no ar. ## Perguntas ### Preciso sair da ferramenta? Não no primeiro dia. O código vai primeiro para o seu repositório; a ferramenta pode continuar gerando telas enquanto as partes arriscadas passam para código revisado. ### Quanto tempo leva o diagnóstico? A semana de discovery termina num plano escrito por estágio, com o que entra, até quando e por quanto. Se você parar aí, o plano é seu. ## Fontes - [Lovable, Connect to Supabase](https://docs.lovable.dev/integrations/supabase) - [Supabase, Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security) ## Tenha o plano antes do código A semana de discovery termina num plano por estágio para o seu app, com preço fixo para cada estágio. - Ver a Discovery: https://thorfyn.com/pt/discovery - Próxima nota: https://thorfyn.com/pt/notes/migrar-do-bubble-para-codigo - Dúvidas e pedidos: hello@thorfyn.com - Voltar para a página inicial: https://thorfyn.com/pt