App do Lovable não funciona em produção? Como deixá-lo pronto

Por que meu app do Lovable funciona na prévia mas quebra em produção?

Na prévia você é um único usuário, com dados de teste, clicando nos caminhos que construiu. A produção acrescenta desconhecidos, dinheiro de verdade e tempo. As falhas que vêm depois raramente são uma linha de código ruim. São decisões que faltaram: quem pode ler qual linha, o que acontece quando um pagamento dá certo mas o navegador fecha, e quem percebe quando um e-mail para de ser enviado.

• Vazamento de dados entre usuários. O Supabase deixa uma tabela de um schema exposto legível e gravável por qualquer papel com permissão sobre ela, a menos que a segurança em nível de linha esteja ativada e suas políticas estejam corretas.
• Segredos no navegador. A chave publicável (anon) pode ir para o navegador; a chave service role ignora todas as políticas de RLS e nunca deve chegar ao navegador.
• Pagamentos que se desencontram. Um checkout que volta para uma página de sucesso não é prova de pagamento. O servidor precisa confirmá-lo com a Stripe.
• Mudanças que quebram funcionalidades antigas. Sem testes de regressão, cada novo prompt pode desfazer algo que funcionava na semana passada.
• Quedas silenciosas. Sem monitoramento, seus clientes encontram o bug antes de você.

Nada disso é exclusivo do Lovable. Qualquer primeira versão rápida, escrita por uma pessoa ou por IA, tende a ter as mesmas lacunas, porque o papel de um protótipo é provar a ideia, não sobreviver a desconhecidos.

Um app do Lovable já vem pronto para produção?

Em parte. A própria documentação do Lovable diz que ele escreve políticas de segurança em nível de linha para as tabelas quando você conecta o Supabase, roda uma varredura rápida de segurança quando você publica (uma revisão do banco de dados, como tabelas sem RLS ou regras que deixam todo mundo passar, uma auditoria de dependências e uma verificação de servidor MCP) e oferece uma varredura mais profunda que você inicia manualmente. Ela também diz, com todas as letras, que a varredura não pode garantir segurança completa e não substitui uma revisão de segurança minuciosa.

É uma descrição justa. Uma varredura pode dizer que uma política existe. Não pode dizer se a política corresponde às suas regras de negócio, por exemplo, que um administrador da equipe pode ver faturas mas um membro da equipe não. Esse julgamento é o que pronto para produção significa na prática.

O que significa estar pronto para produção para um app do Lovable?

Como adicionar pagamentos com a Stripe a um app do Lovable com segurança?

A integração do Lovable com a Stripe roda por meio de edge functions, então sua chave secreta fica fora do app, e pagamentos avulsos abrem o Stripe Checkout. Segundo a documentação do Lovable, ela não configura webhooks por padrão: o app consulta o status de pagamentos e assinaturas diretamente na Stripe, e webhooks podem ser adicionados sob pedido. Ela também observa que os IDs de preço são diferentes entre o modo de teste e o modo live, então ir ao ar exige novos IDs.

Consultar o status sob demanda funciona para um checkout simples. Quando você vende assinaturas, normalmente quer webhooks também, porque renovações, cartões recusados e cancelamentos acontecem quando seu usuário não está na página. A documentação da Stripe é específica sobre como fazer isso com segurança:

• Verifique todo webhook com o cabeçalho Stripe-Signature e o segredo do seu endpoint, contra o corpo bruto da requisição.
• Espere eventos duplicados e fora de ordem. Registre os IDs dos eventos já processados para que cada um seja tratado uma única vez (idempotência).
• Lembre-se de que a Stripe reenvia entregas com falha no modo live por até três dias, então um endpoint quebrado pode reprocessar dias de eventos quando voltar.
• Mantenha os segredos de teste e de produção separados. Objetos de um modo não aparecem no outro.

Devo corrigir sozinho, contratar um freelancer ou trazer uma equipe?

Se seu app tem poucos usuários, nenhum pagamento e nenhum dado sensível, você mesmo pode percorrer a tabela acima com a varredura de segurança do Lovable e o Security Advisor do Supabase, que aponta tabelas com RLS desativado e políticas que deixam todo mundo passar. É um bom uso de uma tarde.

Um freelancer ou um sprint de resgate de preço fechado serve para um problema conhecido e delimitado: uma integração quebrada, uma auditoria. Muitas vezes são a opção mais barata para isso. O que uma correção pontual não dá são os próximos seis meses: os testes, os releases, as atualizações e o incidente fora do horário comercial. Essa responsabilidade contínua é o que vendemos: a Plutonapps é especializada em levar apps do Lovable para produção e operá-los, e nossa comparação entre agências, freelancers, contratação interna e assinaturas mostra quando cada um faz sentido.

O que acontece depois do lançamento, e quem fica de plantão?

O lançamento é onde o trabalho muda, não onde ele para. Alguém precisa acompanhar erros, aplicar atualizações de segurança, responder a incidentes e entregar a próxima funcionalidade sem quebrar a anterior. No nosso plano Starter, os fundadores continuam escrevendo prompts no Lovable, e nossos engenheiros transformam cada versão no produto real, rodam testes de regressão e de regressão visual, revisão de código e verificações de segurança em toda mudança, fazem deploy em produção duas vezes por semana e atendem até cinco eventos de emergência em produção por mês, com suporte em horário comercial. O Growth acrescenta deploy contínuo e suporte 24/7. Detalhes e preços estão na nossa página de preços.