Saindo do Lovable: como assumir e evoluir o código do seu app

O Lovable é bom para levar um produto aos primeiros usuários. Em algum momento, muitos fundadores batem na mesma parede: cada mudança quebra outra coisa, uma funcionalidade precisa de um backend de verdade, ou um desenvolvedor entra no time e quer trabalhar no próprio editor. A pergunta, então, não é se o Lovable foi um erro. É como assumir o controle total do que você construiu sem começar do zero.

Este post fala do que já é seu, de como tirar o código de lá e de quando faz sentido ficar. Ele faz parte do guia para preparar um protótipo construído com IA para usuários reais.

O que é realmente seu?

Mais do que a maioria dos fundadores imagina. A integração do Lovable com o GitHub cria um repositório privado para o projeto, mantém esse repositório sincronizado nos dois sentidos e o deixa onde está se você desconectar: “Seu repositório continua no GitHub”, e o código é seu para baixar, fazer deploy ou gerenciar de forma independente (Lovable).

Mas o código é só uma das coisas das quais o seu app depende. Antes de mexer nele, liste todas as contas de que o app depende e verifique quem é o dono de cada uma:

Se alguma delas pertence a um freelancer, a um email pessoal ou à própria conta do construtor, resolva isso primeiro. É o passo mais difícil de fazer depois, sob pressão.

Como tirar o código de lá?

O caminho que a maioria dos times segue, em ordem:

1. Conecte o GitHub e confira a sincronização. Nas configurações do projeto, conecte o repositório e confirme que as últimas mudanças aparecem lá. O Lovable sincroniza um branch por vez, normalmente o branch padrão.
2. Rode localmente. Clone o repositório, instale as dependências e crie o arquivo de ambiente com as variáveis que o app usa. Um app do Lovable é um projeto React padrão, então qualquer desenvolvedor consegue rodá-lo.
3. Faça o deploy na sua própria hospedagem. Conecte o repositório a uma hospedagem como Vercel ou Netlify, configure lá as variáveis de ambiente e faça o deploy de um preview. Teste o fluxo completo: cadastro, a funcionalidade principal, pagamentos.
4. Mova o domínio. Aponte seu domínio para a nova hospedagem só depois que o preview funcionar, e mantenha o deploy antigo por alguns dias caso precise voltar.
5. Decida como o Lovable entra daqui para frente. Você pode continuar usando o Lovable para trabalho de interface, já que as mudanças enviadas ao GitHub voltam sincronizadas para ele. Ou desconectar e trabalhar só no código. O repositório continua lá de qualquer jeito.

Para um app pequeno, a migração em si costuma levar um ou dois dias de trabalho. O trabalho que vem depois é a parte que as ferramentas de IA pularam: regras de acesso ao banco de dados, verificações no servidor e testes. As dez verificações antes dos usuários reais são o ponto de partida, junto com a row level security do Supabase e as chaves secretas no frontend.

Quando você deve continuar no Lovable?

Fique enquanto o produto ainda está encontrando a sua forma. Se você muda telas todo dia, testa ideias com poucos usuários e ninguém além de você mexe no código, a velocidade do Lovable vale mais do que uma base de código limpa.

Migre quando uma destas situações se tornar realidade:

• As mudanças quebram funcionalidades não relacionadas, e não há testes para dizer o que quebrou.
• Você precisa de lógica de backend que o construtor resolve mal: jobs agendados, processamento pesado, integrações com outros sistemas, permissões complexas.
• Um desenvolvedor entra no time e precisa trabalhar com branches, code review e as próprias ferramentas.
• Você está prestes a receber dinheiro de verdade ou lidar com dados sensíveis, e precisa de alguém responsável por como isso é tratado.

O que muda depois da migração?

O código deixa de ser algo que uma ferramenta regenera e passa a ser algo que o seu time mantém. Isso significa alguns hábitos que o protótipo não precisava: as mudanças passam por pull requests, o schema do banco de dados muda por migrações em vez do painel, e cada deploy é reproduzível a partir do repositório. Nada disso é pesado, mas é a diferença entre um app que você demonstra e um app que você opera.