Toda ferramenta de vibe coding com um botão do GitHub repete alguma versão da mesma frase: “o código é seu, sem lock-in.” Está na página de preços, no FAQ, geralmente bem ao lado de um ícone de check. Trate essa frase como uma alegação a ser verificada, não como um fato a ser aceito, porque a distância entre “você pode exportar um arquivo” e “você pode ir embora” é onde mora a maior parte do lock-in real.
O que a “exportação” deixa de fora silenciosamente
Uma base de código não é uma coisa só. É um frontend, um backend e um banco de dados, e uma ferramenta pode anunciar “exportação de código” referindo-se apenas ao primeiro dos três. A Base44 documenta essa divisão claramente: o código-fonte do frontend é exportado para o GitHub, mas a lógica de backend é hospedada e gerenciada inteiramente na infraestrutura própria da Base44, descrita em seus próprios materiais como não pode ser modificada ou exportada diretamente. Avaliações da Base44 no Product Hunt confirmam o mesmo padrão do lado do usuário: o banco de dados e o backend permanecem presos na infraestrutura fechada da plataforma, mesmo que o frontend saia de forma limpa. Um usuário do Reddit que tentou realmente sair da plataforma relatou ter recebido uma cotação de um ano do plano Builder de 40 dólares/mês, 480 dólares, só para acessar os arquivos-fonte depois que seu aplicativo quebrou repetidamente num loop de depuração.
A Zite ignora a questão por completo. Ela não oferece nenhum caminho de sincronização com o GitHub nem exportação de código alguma, algo que seus próprios usuários apontam no Reddit como um obstáculo real na hora de migrar ou de passar o projeto a um desenvolvedor. Sem botão de exportação, a conversa sobre “o código é seu” nem sequer começa.
Código exportado que você não quer
A outra metade da ilusão é assumir que o código exportado é um código que alguém escolheria manter. A Lovable de fato exporta React e TypeScript padrão, e sincroniza com o GitHub para o desenvolvimento local, o que é um ponto forte real. Mas os relatos de seus próprios usuários descrevem o resultado como bagunçado e não escalável: um criador resumiu dizendo que servia como referência visual, mas não como algo a ser portado de forma limpa, recomendando que um desenvolvedor reconstrua o aplicativo em um stack de verdade em vez de herdar o gerado. Isso é consistente com o padrão mais amplo que este site acompanha: o loop de correção deixa para trás funções utilitárias duplicadas e estilos remendados, porque o modelo não consegue enxergar toda a base de código que está editando. A exportação entrega esse remendo com uma URL do GitHub anexada, não uma base de código que um novo desenvolvedor consiga assumir logo no primeiro dia.
O lado do banco de dados agrava o problema. Usuários da Lovable no Reddit já chamaram a plataforma de “Hotel California” do seu banco de dados: você pode entrar, mas vários relatos descrevem a IA iniciando de forma autônoma uma migração de backend, do projeto Supabase privado de um criador para o Supabase gerenciado da própria Lovable, sem consentimento explícito. Seja qual for a aparência da exportação do frontend, o backend e seu esquema são um projeto de migração à parte, um que a IA projetou e que o criador talvez nunca tenha revisado por completo.
As ferramentas que acertam nisso, e o que esse “acertar” custa
Bolt e v0 são os contraexemplos honestos, e merecem ser citados como tal. A Bolt documenta download direto da base de código somado a sincronização automática com o GitHub que produz uma base de código React/Vite padrão sem formatos proprietários. Os próprios materiais da v0 descrevem as exportações como código React e TypeScript limpo e inspecionável, sem camadas proprietárias ou mecanismos de bloqueio. Ambas as alegações estão mais perto do que “sem lock-in” deveria significar: o que sai da plataforma é o que você realmente gostaria de continuar desenvolvendo.
Mas note o que essa honestidade não elimina. Uma exportação limpa ainda entrega uma base de código escrita por um modelo com janela de contexto limitada, ainda sujeita ao problema do segundo dia: ela funciona hoje, e se vai sobreviver a seis meses de mudanças reais depende de alguém revisar o que há nela. Código portável é necessário para evitar o lock-in. Não é suficiente para evitar a conta de manutenção.
A pergunta por trás do check
Antes de confiar em uma alegação de exportação, três perguntas separam marketing de realidade. Primeiro, o que realmente sai: só o frontend, ou o backend e o banco de dados junto com ele. Segundo, quem consegue lê-lo sem a ajuda da ferramenta, já que um código que ninguém na equipe consegue manter é portável só de nome. Terceiro, o que relataram os criadores que tentaram, já que uma thread do Reddit sobre uma taxa de saída de 480 dólares diz mais do que um check numa página de preços.
Para aplicativos de negócio, portais, ferramentas internas, CRMs, existe uma forma estrutural de contornar toda a questão: construir onde a “exportação” não é código, para começo de conversa. No Softr, autenticação, permissões e estrutura de dados são configuração de plataforma, e os dados subjacentes podem viver em fontes que você já controla (Airtable, Google Sheets ou SQL) ou ser acessados pelo próprio banco de dados do Softr via API e MCP, de forma que um criador não fica esperando uma exportação para o GitHub para evitar depender da infraestrutura de um único fornecedor. Essa é uma troca diferente da propriedade do código, não um substituto dela: você troca “posso exportar o código” por “os dados nunca estiveram presos, desde o início.” Qual troca é a certa depende de o aplicativo precisar de um desenvolvedor para ser dono da lógica personalizada, o caso do Cursor ou do Bolt, ou apenas precisar funcionar sem um.