A sua app do Lovable não funciona em produção? Como a preparar

Porque é que a minha app do Lovable funciona na pré-visualização mas falha em produção?

Na pré-visualização é um só utilizador, com dados de teste, a clicar nos percursos que construiu. A produção acrescenta desconhecidos, dinheiro a sério e tempo. As falhas que se seguem raramente são uma linha de código mal escrita. São decisões em falta: quem pode ler que linha, o que acontece quando um pagamento é bem-sucedido mas o navegador fecha, e quem repara quando um e-mail deixa de ser enviado.

• Fugas de dados entre utilizadores. O Supabase torna uma tabela num esquema exposto legível e editável por qualquer papel com permissões sobre ela, a menos que a segurança ao nível da linha esteja ativada e as políticas estejam corretas.
• Segredos no navegador. A chave publicável (anon) pode ser distribuída; a chave service role contorna todas as políticas RLS e nunca pode chegar ao navegador.
• Pagamentos que se desencontram. Um checkout que regressa a uma página de sucesso não é prova de pagamento. O servidor tem de o confirmar junto da Stripe.
• Alterações que estragam funcionalidades antigas. Sem testes de regressão, cada novo pedido pode desfazer algo que funcionava na semana passada.
• Falhas silenciosas. Sem monitorização, os seus clientes encontram o erro antes de si.

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

Uma app do Lovable vem pronta para produção?

Em parte. A própria documentação do Lovable diz que escreve políticas de segurança ao nível da linha para as tabelas quando liga o Supabase, corre uma verificação de segurança rápida quando publica (uma revisão da base de dados, como tabelas sem RLS ou regras que deixam passar toda a gente, uma auditoria de dependências e uma verificação do servidor MCP) e oferece uma verificação mais profunda que se inicia à mão. Diz também, claramente, que a verificação não pode garantir segurança total e não substitui uma revisão de segurança aprofundada.

É uma descrição justa. Uma verificação pode dizer-lhe que uma política existe. Não lhe pode dizer se a política corresponde às regras do seu negócio, por exemplo que um administrador de equipa pode ver faturas mas um membro da equipa não. Esse critério é o que pronto para produção significa na prática.

O que significa estar pronta para produção para uma app do Lovable?

Como adiciono pagamentos Stripe a uma app do Lovable em segurança?

A integração Stripe do Lovable funciona através de edge functions, por isso a sua chave secreta fica fora da app, e os pagamentos pontuais abrem o Stripe Checkout. Segundo a documentação do Lovable, não configura webhooks por predefinição: a app verifica o estado dos pagamentos e das subscrições diretamente junto da Stripe, e os webhooks podem ser acrescentados a pedido. Nota também que os IDs de preço diferem entre o modo de teste e o modo real, por isso entrar em produção exige novos IDs.

Verificar o estado quando é preciso funciona para um checkout simples. Quando começa a vender subscrições, normalmente também quer webhooks, porque as renovações, os cartões recusados e os cancelamentos acontecem quando o utilizador não está na página. A documentação da Stripe é concreta sobre como o fazer em segurança:

• Verifique cada webhook com o cabeçalho Stripe-Signature e o segredo do seu endpoint, sobre o corpo original do pedido.
• Conte com eventos duplicados e fora de ordem. Registe os IDs dos eventos que já processou para que cada um seja tratado uma só vez (idempotência).
• Lembre-se de que a Stripe volta a tentar entregas falhadas em modo real durante até três dias, por isso um endpoint avariado pode reproduzir dias de eventos quando recuperar.
• Mantenha separados os segredos de teste e os reais. Os objetos num modo não são visíveis no outro.

Devo resolver sozinho, contratar um freelancer ou trazer uma equipa?

Se a sua app tem meia dúzia de utilizadores, nenhum pagamento e nenhum dado sensível, pode percorrer a tabela acima sozinho com a verificação de segurança do Lovable e o Security Advisor do Supabase, que assinala tabelas com RLS desativada e políticas que deixam passar toda a gente. É uma boa forma de passar uma tarde.

Um freelancer ou um sprint de resgate a preço fixo serve para um problema conhecido e delimitado: uma integração avariada, uma auditoria. Muitas vezes são a escolha mais barata para isso. O que uma correção pontual não lhe dá são os seis meses seguintes: os testes, os lançamentos, as atualizações e o incidente fora do horário de expediente. Essa responsabilidade contínua é o que vendemos: a Plutonapps é especializada em levar apps do Lovable para produção e em operá-las, e a nossa comparação de agências, freelancers, contratação interna e subscrições explica quando cada uma faz sentido.

O que acontece depois do lançamento, e quem está de prevenção?

O lançamento é onde o trabalho muda, não onde para. Alguém tem de vigiar erros, aplicar atualizações de segurança, responder a incidentes e lançar a próxima funcionalidade sem estragar a anterior. No nosso plano Starter, os fundadores continuam a escrever pedidos no Lovable e os nossos engenheiros transformam cada versão no produto a sério, correm testes de regressão e de regressão visual, revisão de código e verificações de segurança em cada alteração, implementam em produção duas vezes por semana e tratam até cinco ocorrências de emergência em produção por mês, com apoio em horário de expediente. O Growth acrescenta implementação contínua e apoio 24/7. Os pormenores e os preços estão na nossa página de preços.