Como transformar um protótipo do Lovable em SaaS

O que o Lovable, o Bolt e o v0 fazem bem?

Essas ferramentas são boas em transformar uma ideia em telas clicáveis, com login, banco e um fluxo principal funcionando, em horas ou dias. O resultado é código React de verdade, geralmente ligado ao Supabase, que mostra a ideia pra cliente e investidor e prova se alguém usa. Pra validar, poucas coisas são tão baratas.

Cada uma tem um perfil. O Lovable gera a aplicação inteira com Supabase por trás e sincroniza o código com o GitHub nos dois sentidos; a documentação da integração com GitHub diz que dá pra publicar fora do Lovable e baixar o código nos planos pagos. O Bolt usa por padrão um banco próprio, o Bolt Database, e oferece o Supabase como alternativa. O v0, da Vercel, é mais forte em interface. O Base44 roda sobre um backend gerenciado pela própria plataforma, o que pesa na hora de sair.

Elas geram o que você pede, e quase ninguém pede isolamento entre clientes, idempotência de webhook ou plano de backup antes do primeiro problema.

Onde o protótipo trava quando entram clientes pagando?

Trava em tudo que só aparece com mais de um cliente e com dinheiro de verdade: a conta da empresa com vários usuários, o papel de cada pessoa, a assinatura que falha e volta, o banco que cresce e muda de estrutura, e a segurança que ninguém testou. A tabela resume o que encontramos ao abrir esses projetos.

A cobrança merece um exemplo concreto. A documentação da integração do Lovable com a Stripe, na leitura de outubro de 2026, diz que por padrão a integração não usa webhooks: o app consulta o status direto na Stripe, e a assinatura é reconhecida quando o e-mail de login bate com o e-mail do cliente na Stripe. Pra validar, resolve. Num SaaS B2B, quem paga é a empresa, o e-mail do financeiro raramente é o de quem usa, e o acesso precisa mudar quando o cartão falha. O desenho que aguenta isso está em cobrança recorrente em SaaS.

Conta por cliente é o outro ponto de quebra: protótipo gerado amarra cada dado ao usuário que o criou, SaaS amarra ao tenant. Detalhes em multi-tenant: como estruturar o banco do seu SaaS.

Como saber se o protótipo tem brecha de segurança?

O teste mais rápido mira o que a OWASP coloca em primeiro lugar: controle de acesso quebrado. Crie dois usuários de clientes diferentes e tente ler, pelo navegador ou pela API, o dado de um com a sessão do outro. Se conseguir, o protótipo não está pronto pra cliente pagante, independente do resto.

No OWASP Top 10 2025, Broken Access Control é o A01, e configuração insegura vem logo atrás, no A02. Em projeto com Supabase, as duas brechas costumam ter a mesma origem: tabela sem Row Level Security. O checklist de produção do Supabase é direto: tabela sem RLS habilitado e sem políticas razoáveis deixa qualquer cliente acessar e modificar os dados. Como a chave pública do Supabase vai pro navegador por desenho, a política no banco é a única porta.

• RLS em todas as tabelas, com política que filtra por tenant, e não só por usuário.
• Nenhuma chave secreta no front. A chave de serviço do Supabase ignora o RLS; se ela aparece no código que vai pro navegador, qualquer pessoa tem acesso total ao banco.
• Funções do servidor checando quem chama. Devolver o registro de um ID sem conferir o dono é a brecha mais comum que encontramos.
• Dependências atualizadas e sem pacote abandonado. Falha na cadeia de fornecimento de software virou o A03 da lista da OWASP.
• Limite de tentativas no login e em endpoints que custam dinheiro, como chamadas de IA.

O próprio Lovable ajuda nisso: a página de segurança descreve uma varredura automática na publicação, que olha as regras de acesso do banco, e uma varredura mais profunda sob demanda. A mesma página diz que a responsabilidade de atender os requisitos de segurança do app é sua e que as ferramentas não substituem uma revisão completa. A varredura ajuda, mas não assina por você.

O que dá para aproveitar do protótipo?

Quase sempre dá pra aproveitar o fluxo validado, o desenho das telas, os dados que já estão no Supabase e a conta da Stripe ou do Mercado Pago com os clientes dentro. O que costuma ser refeito fica embaixo da tela: modelo de dados, políticas de acesso, cobrança e funções do servidor.

• O fluxo e as telas. Viraram especificação testada por gente real, e às vezes os componentes visuais entram quase inteiros na versão nova.
• O banco no Supabase. Se o projeto está numa conta sua, o Postgres continua o mesmo e ganha colunas de tenant, migrations e políticas. Os dados dos clientes não precisam mudar de lugar.
• A conta do processador de pagamento. Clientes, assinaturas e cartões salvos ficam na Stripe ou no Mercado Pago, então trocar a aplicação não obriga ninguém a recadastrar o cartão.
• O aprendizado. O que os usuários ignoraram sai do escopo, e isso corta mais custo que qualquer código reaproveitado.

Um alerta pra quem está no Bolt: a documentação da integração com o Supabase explica que o Bolt Database é o padrão, que trocar pra Supabase depois exige passos extras e que não há caminho suportado de volta. Se o produto vai ter clientes pagando, decida cedo onde os dados vão morar e deixe o banco numa conta no seu nome.

Quando vale reescrever em vez de consertar?

Vale reescrever quando o modelo de dados não tem a noção de cliente, quando a regra de negócio está espalhada pelas telas e quando cada correção quebra outra coisa. Vale consertar quando o banco já está bem modelado e o problema se limita a políticas, segredos e testes. A decisão sai de ler o código, não de opinião.

Se mudar uma regra simples, como o limite de usuários por plano, mexe em dez arquivos, o problema é estrutural. Quando o código está em React com Supabase, como o Lovable gera, o caminho do meio costuma ser o mais barato, porque banco e cobrança atravessam a troca inteiros.

Quanto custa e quanto tempo leva transformar o protótipo em SaaS?

Depende de qual dos três caminhos o código permite, e ninguém deveria cravar número sem abrir o repositório. Na VTA, lemos o código e o banco, devolvemos o plano por escrito e fechamos escopo, prazo e preço antes de começar. Projetos começam em R$ 20 mil, e uma primeira versão de SaaS entra no ar em até 10 semanas.

O que mais move o valor: quantos tipos de conta e papel o produto precisa, se a cobrança é um plano só ou por uso, quantas integrações existem e quanto dado real precisa ser migrado. O protótipo também reduz o custo: o escopo chega validado, e cada hora vai pra algo que alguém já usa. As faixas de mercado e o cálculo por esforço estão em quanto custa criar um SaaS.

E quando não vale contratar ninguém ainda? Se ninguém pagou, continue iterando no Lovable ou no Bolt. Se o orçamento está abaixo do nosso piso, um desenvolvedor de confiança pode ativar o RLS, tirar segredos do front e ligar os webhooks, fechando as brechas mais graves enquanto a receita cresce. Software house faz sentido quando há cliente pagando e dados e dinheiro de terceiros em jogo.

Como migrar sem parar quem já usa o produto?

Migrando por etapas, com o protótipo no ar até a versão nova provar que faz o mesmo. Primeiro o código vai pro seu GitHub e o banco ganha migrations; depois a aplicação nova sobe em homologação com uma cópia dos dados; por fim, a virada acontece num horário combinado, com caminho de volta pronto.

• Inventário. Repositório no seu GitHub, banco e processador de pagamento em contas no seu nome, lista de segredos e de integrações.
• Auditoria. Teste de acesso entre clientes, revisão de RLS, segredos e funções do servidor, com os riscos em ordem de prioridade.
• Correções urgentes primeiro. O que vaza dado ou dinheiro é fechado no protótipo atual, antes de qualquer reescrita.
• Modelo de dados com tenant. Migrations versionadas, coluna de cliente, índices e políticas, com um teste automatizado que prova que um cliente não vê o outro.
• Aplicação nova em homologação, ligada à mesma conta do processador em modo de teste e com webhooks verificados.
• Virada e operação. Migração ensaiada, monitoramento ligado e backup testado. No plano gratuito do Supabase o backup não fica disponível pra download, e o checklist de produção recomenda o PITR quando o banco passar de 4 GB.

É o padrão da Velify, SaaS de dropshipping por assinatura que construímos (não a partir de protótipo de IA): Postgres no Supabase com RLS por papel, 22 migrations versionadas e mais de 1.400 testes automatizados.

Se o seu protótipo já tem cliente batendo na porta, mande o link do repositório pela página de orçamento ou veja o que entra em desenvolvimento de SaaS. A resposta sai no mesmo dia, e a proposta vem com escopo, prazo e preço fechados.

Perguntas frequentes