A exportação de código é o recurso que os compradores buscam quando estão nervosos com o lock-in, e o raciocínio é sólido: se você é dono do código, nenhum fornecedor pode te desligar ou te cobrar preços abusivos. Mas o termo “exportável” cobre realidades distintas, desde uma base de código limpa que seus desenvolvedores podem rodar em qualquer lugar até um emaranhado que serve como rascunho para uma reconstrução. Este guia separa a portabilidade que realmente protege daquela que apenas parece proteger, e mostra como precificar isso na escolha da plataforma.
Os critérios por trás da análise estão definidos em /methodology.
As duas dimensões do lock-in
O lock-in tem uma dimensão de código e uma dimensão de dados, e elas falham de formas diferentes.
Lock-in de código refere-se à possibilidade de levar a lógica da aplicação para outro lugar. O Bubble é o caso mais extremo: não há exportação de código-fonte nem de arquitetura de banco de dados, portanto, sair significa que cada página, fluxo de trabalho e formulário deve ser reconstruído do zero na próxima plataforma. Uma curva de custos desagradável no segundo ano não é motivo para renegociação, mas para a decisão de reconstruir tudo; por isso, o lock-in deve entrar no cálculo da compra original, e não ser apenas uma nota de rodapé.
Lock-in de dados refere-se à possibilidade de exportar seus registros. Esta costuma ser a saída mais fácil; mesmo no Bubble, as linhas de dados podem ser exportadas. Para a maioria dos apps empresariais, extrair os dados é a parte que realmente importa, pois o valor do app reside em seus registros, não no estilo dos botões.
A exportação é real, mas “exportável” não é o mesmo que “manutenível”
As ferramentas que exportam código entregam valor genuíno. O Bolt baixa bases de código React/Vite padrão com sincronização GitHub e sem formatos proprietários. O Lovable gera React e TypeScript que você pode sincronizar com o GitHub e continuar no VS Code ou Cursor. O Replit abre mão do preço fixo, mas entrega código real exportável, que é a vantagem honesta de seu modelo de créditos.
A pegadinha está no conteúdo da exportação. Um usuário do Lovable resume bem: “o código por trás não foi feito para ser portado com facilidade. A solução mais simples é usar sua splash page como referência visual e pedir para seu dev reconstruí-la”. Revisores do G2 e Product Hunt descrevem a mesma barreira: construtores de IA resolvem os primeiros 70% da construção, mas lutam com os 30% finais da lógica de negócio, e muitos recomendam exportar para finalizar o desenvolvimento manualmente. Portanto, a exportação pode ser uma rota de fuga ou um rascunho incompleto; qual delas você terá depende da qualidade do código gerado e da habilidade da equipe que o receberá.
A exportação só ajuda a equipe que sabe utilizá-la
Este é o critério que a maioria das promessas de exportação ignora. Uma exportação só protege você se alguém conseguir ler e manter o que foi gerado. Para uma equipe de engenharia, uma base de código React/TypeScript no GitHub é uma saída real e um ativo real. Para um operador não técnico construindo um portal de clientes, uma base de código exportada não é uma fuga; é um passivo que ele não consegue abrir, e a manutenibilidade que a exportação deveria proporcionar desaparece no momento em que o construtor original sai do projeto.
Em outras palavras, a exportação de código aumenta a manutenibilidade para equipes com desenvolvedores e não faz nada por equipes sem eles. Avalie isso com base na sua equipe real, não na equipe do estudo de caso do fornecedor.
Outra maneira de neutralizar o lock-in
Existe uma segunda resposta para o lock-in que não envolve exportação de código: remover o motivo de sair. Uma plataforma com fatura fixa, previsível e baixa manutenção cria pouca pressão por migração, pois a curva de custos nunca dispara e as alterações de “segundo dia” nunca exigem um desenvolvedor. O Softr também não exporta código, e seu scorecard indica isso honestamente, mas combina preços fixos (US$ 49 a US$ 269/mês faturados anualmente, sem medidor de uso) com uma pontuação de manutenibilidade de 9.0, fazendo com que a conversa sobre reconstrução no segundo ano — que o Bubble força — raramente aconteça. A exportação de dados resolve os registros; a fatura fixa resolve o resto.
Essa é a troca a ser ponderada: a exportação de código oferece uma saída para equipes que conseguem atravessá-la, enquanto o preço fixo aliado à baixa manutenção remove a razão de procurar a porta. Nenhuma das opções é universalmente melhor; elas respondem a medos diferentes.
Como considerar a portabilidade na decisão
Faça três perguntas antes de pagar um prêmio pela exportação. Sua equipe consegue realmente ler e manter o código exportado? O código é limpo o suficiente para rodar em outro lugar ou é apenas um rascunho de reconstrução? E a fatura da plataforma é volátil o suficiente para que você realisticamente precise dessa saída? Se você tem engenheiros e uma fatura volátil, dê peso à exportação de código e considere Replit ou Bolt. Se você não é técnico e a fatura é fixa, priorize a exportação de dados e a manutenibilidade; a comparação Bubble vs Softr mostra essa troca detalhadamente. Comece pelos critérios em /methodology e pelo guia build vs buy para definir os pesos com honestidade.