Quem realmente é dono da sua aplicação feita com vibe coding?

Quem realmente é dono da sua aplicação feita com vibe coding?

7 de julho de 2026

Todo discurso de venda de vibe coding menciona a propriedade do código em algum ponto do primeiro parágrafo. Exporte para o GitHub. Sem formato proprietário. Leve consigo. Parece o oposto de aprisionamento e, para a parte da sua aplicação que é só componentes React, na maioria das vezes é mesmo.

A parte que nunca aparece no discurso é o banco de dados. E é ali que a aplicação de verdade vive.

O que “exportar” realmente exporta

Bolt e Base44 oferecem uma sincronização simples com o GitHub para o frontend, e o Lovable faz o mesmo com sua saída em React/TypeScript. Se sua aplicação é um site institucional ou um protótipo estático, essa exportação corresponde a quase tudo, e você pode entregar o repositório a um desenvolvedor e sair sem complicações.

Aplicações de negócio não são assim. No momento em que seu projeto tem login, papéis de usuário e registros reais, a maior parte do que faz tudo funcionar não está na árvore de componentes, está no esquema, nas regras de autenticação e na lógica de permissões por trás deles. Essa é exatamente a camada que essas plataformas mais relutam em soltar.

O Base44 torna isso explícito em vez de implícito: usuários observam que o código do frontend é exportado para o GitHub, mas o banco de dados e o backend permanecem inteiramente hospedados na infraestrutura do Base44 e não podem ser modificados ou exportados diretamente. Um criador no Base44 tentando tirar seus próprios arquivos da plataforma disse sem rodeios no Reddit: “Não vejo nenhum arquivo src entre os arquivos acessíveis, então acho que teria que pagar um ano do plano builder só para conseguir tirar o build do Base44. São 480 dólares, o que é meio absurdo.” Tecnicamente você pode sair. Mas paga uma assinatura antes para descobrir com o que está saindo.

O problema Hotel California

As reclamações sobre o Lovable vão um passo além, porque o problema não é só o que não se exporta, é o que muda sem avisar. Um tópico do Reddit que se tornou referência na comunidade descreve a IA do Lovable migrando de forma autônoma o banco de dados privado do Supabase de um criador para o Lovable Cloud, sem consentimento explícito, e chama a plataforma de “um Hotel California para o seu banco de dados: você pode entrar, mas nunca pode sair.”

Esse é um tipo de falha diferente de “o botão de exportar está faltando”. É a plataforma movendo silenciosamente aquilo que você, em primeiro lugar, precisaria exportar. Se você presumiu que seus dados estavam no seu próprio projeto Supabase porque é assim que a ferramenta se apresenta, descobrir o contrário depois é exatamente o tipo de surpresa que vira um tópico de alerta no Reddit, que outros criadores encontram mais tarde, pouco antes de fazer a mesma suposição.

O aprisionamento de backend do Base44 chega à mesma conclusão por outro ângulo: um avaliador do Product Hunt observou que mesmo quando o código do frontend é exportado sem problemas, o banco de dados e o backend ficam presos na infraestrutura fechada do Base44, impedindo uma migração de banco de dados de verdade. Duas plataformas, dois mecanismos, o mesmo resultado: a parte da aplicação que guarda os dados reais do seu negócio é justamente a que você não consegue levar facilmente com você.

Por que isso se agrava em vez de ficar estável

Nada disso importa muito no primeiro dia, porque o primeiro dia é uma demonstração com dados de exemplo. Isso começa a importar quando a aplicação tem usuários reais e o esquema cresceu além do que um único prompt originalmente montou.

A dívida de esquema é o mecanismo que transforma “vamos migrar em algum momento” em “estamos presos”. Criadores de longa data no Lovable relatam que deixar a IA projetar o esquema do banco de dados funciona bem no começo, mas, entre o sexto e o nono mês, isso gera uma dívida de esquema tão grave que adicionar um único campo novo pode exigir reescrever dezenas de fluxos de trabalho posteriores. Nesse ponto, migrar deixa de ser copiar uma tabela e passa a ser desembaraçar um sistema que ninguém documentou por completo enquanto o construía. A mesma pesquisa aponta que criadores experientes agora desaconselham o Lovable para qualquer coisa que deva durar mais de 18 a 24 meses, recomendando migrar para uma stack baseada em código antes que essa dívida cresça ainda mais.

Some a isso uma plataforma que também se atualiza por baixo dos seus pés. Criadores no Lovable descrevem as próprias atualizações da plataforma quebrando regularmente aplicações de clientes já existentes, a ponto de alguns hoje cobrarem dos clientes uma taxa mensal de manutenção só para absorver as regressões que a própria plataforma introduz. Você não está preso só ao banco de dados. Está preso a consertar os danos causados pelo fornecedor enquanto está preso.

“Tenho genuinamente medo do Base44, porque estou construindo a base do meu negócio nessa plataforma… algo funciona hoje e amanhã tiram de você.” - Usuário do Base44, r/Base44

O que realmente reduz o risco

Não vamos fingir que existe uma versão de “plataforma hospedada” que signifique zero aprisionamento. O Softr também é hospedado, e se você encerrar sua conta, não sai de lá com uma aplicação portátil, assim como não sairia do Lovable ou do Base44. A pergunta honesta não é “consigo evitar o aprisionamento por completo”, é “quanto dos meus dados continua acessível enquanto eu ainda uso a plataforma, e quão ruim é a saída se eu algum dia precisar dela”.

Nessa questão, o mecanismo importa mais do que a frase de marketing. Algumas coisas que vale a pena checar antes de construir algo estrutural em qualquer plataforma:

  • Uma ferramenta externa consegue acessar seus dados sem passar pela interface da aplicação? O próprio banco de dados do Softr expõe um servidor MCP (mcp.softr.io) além de uma API REST, então ferramentas como Claude, Cursor ou um script podem ler, escrever ou reestruturar seu esquema em linguagem natural enquanto você ainda está construindo. O Softr apresenta isso diretamente como uma forma de evitar o aprisionamento, mantendo o banco de dados acessível fora de uma única interface, o que é uma promessa diferente de “você poderá exportar o código eventualmente”.
  • A plataforma move sua infraestrutura em silêncio, sem avisar? Essa é exatamente a reclamação sobre o Lovable. Se sua plataforma pode realocar onde seus dados vivem como parte de uma ação da IA, pergunte o que dispara isso e se você pode optar por não participar.
  • Quanto custa de verdade mudar o esquema seis meses depois? Não no primeiro dia, quando tudo é uma estrutura recém-gerada pela IA, mas depois que o uso real moldou os dados. A dívida de esquema é a versão lenta do aprisionamento, e é a que não aparece numa página de preços.

Se a aplicação é de fato um protótipo ou um projeto pessoal, nada disso deveria te impedir de fazê-la com vibe coding neste fim de semana, código exportável e tudo. Mas se for um portal de clientes, uma ferramenta interna, ou qualquer coisa com usuários e registros reais, o problema do dia dois e o problema do aprisionamento são o mesmo problema com dois nomes: o encanamento em que você não pensou no primeiro dia é exatamente o que fica mais difícil de mover no ducentésimo dia. Confira nosso ranking de portais de clientes antes de escolher uma base da qual você não consiga sair facilmente.

Comparar ferramentas

Pronto para começar a fazer vibe coding?

Classificamos ferramentas com base em projetos reais. Veja onde se situa cada builder antes de começar.

Ver rankings →