"Lock-in de código e lock-in de operação são coisas diferentes (e o segundo é o que te prende)"
"O código você já consegue levar. O que te prende é o que roda dentro da plataforma, e isso cresce a cada pedido. O mapa e a pergunta pra fazer antes do próximo."
"Consigo sair desta plataforma?"
Essa pergunta está na lista das dúvidas que a pesquisa de mercado deste blog viu crescer em 2026 entre quem constrói com IA. E a resposta que circula ("é só exportar o código") responde metade dela.
Tem uma palavra em inglês pra isso: lock-in, que é ficar preso a um fornecedor porque sair custa caro demais. E existem dois tipos, que quase ninguém separa.
Os dois aprisionamentos
Lock-in de código é quando os arquivos do app não são seus. Esse quase todo mundo já resolveu: Lovable, Bolt e companhia ligam o projeto no GitHub (o site onde o código fica guardado, com histórico). Você leva os arquivos quando quiser.
Lock-in de operação é quando o que faz o app funcionar mora num serviço que só existe dentro da plataforma: o banco, o login, a IA que responde o cliente, o envio de e-mail. O código diz "chame o banco". O banco não vai junto.
Se você achava que estar no GitHub era estar livre, não foi distração sua. O botão de exportar existe e funciona. Ele só resolve o primeiro tipo, e ninguém te mostrou que tinha um segundo.
O que a documentação diz, sem enfeite
Pego o Lovable como exemplo porque é onde a maioria dos leitores está, e porque a documentação dele e a do Supabase (o serviço de banco que roda por baixo) são honestas sobre isso.
Quando o projeto usa o Lovable Cloud, o banco embutido que vem ligado por padrão, a página de suporte do Supabase diz que o banco "não pertence à sua conta do Supabase": é da Lovable. Você não vê o projeto no seu painel e não recebe a chave de serviço, que é a chave mestra do banco. Diz também que não existe jeito automático de passar esse banco pra uma conta sua, e que, depois de ligado, o Cloud "não pode ser desconectado" nem trocado por um Supabase seu. Sair é criar um banco novo e mudar os dados na mão.
A IA embutida segue o mesmo desenho. A documentação do Lovable diz que o recurso de IA pro seu app "sempre roda pela Lovable" e cobra dos créditos do seu espaço de trabalho. Funciona bem e não pede chave nenhuma. Mas é mais um fio que só existe lá dentro.
Nada disso é armadilha. É o preço da comodidade, e tá escrito. O problema é que ele vai sendo pago sem você perceber.
O mapa: o que é seu, e de que tipo
| Peça | Tipo de lock-in | Como saber se é sua |
|---|---|---|
| Código | código | o repositório tá na sua conta do GitHub |
| Banco | operação | o projeto aparece no seu painel do Supabase (ou Firebase) |
| Usuários | operação | moram no banco: se o banco não é seu, eles também não |
| Chaves | operação | você sabe o nome de cada uma e tem acesso à chave mestra |
| Domínio | operação | o endereço tá registrado no seu CPF ou CNPJ |
Repare na proporção. Uma linha de código, quatro de operação. E é por isso que exportar o código não é sair da plataforma: o zip leva a primeira linha.
O que cresce sem você ver
O lock-in de código é fixo: o código tá no GitHub ou não tá.
O de operação cresce a cada pedido. "Adiciona login com Google." "Manda um e-mail quando o pedido fechar." "Coloca uma IA que responde o cliente." Cada pedido desses pode ser atendido com o serviço embutido da plataforma, que é o caminho mais curto pra IA que tá construindo. Cada um é mais um fio. Três meses depois, o app que era um banco e meia dúzia de telas tem nove serviços que só existem lá dentro.
Faz hoje: o raio-x e a pergunta do fio
Duas coisas, dez minutos.
1. O raio-x do que já existe. Cole isto no chat da plataforma, num pedido só:
Não mude nenhum arquivo. Só me responda:
liste todo serviço que este app usa e que funciona por causa
desta plataforma (banco, login, armazenamento de arquivos,
IA, e-mail, tarefas agendadas, funções no servidor).
Pra cada um, diga:
- o nome do serviço
- se ele roda numa conta minha ou na conta da plataforma
- qual seria o equivalente fora daqui
Passe a lista pro papel, uma linha por serviço. A coluna que importa é a do meio: tudo que roda "na conta da plataforma" é lock-in de operação. Não tem nada pra consertar hoje. Tem pra saber.
2. A pergunta do fio, antes do próximo pedido. Daqui pra frente, quando for pedir um recurso novo, acrescente uma linha no fim:
Antes de construir: isso vai usar algum serviço que só existe
dentro desta plataforma? Se sim, qual, e qual seria a opção
que roda numa conta minha?
Às vezes a resposta vai ser "usa o embutido" e você vai aceitar, porque é mais rápido e você ainda tá testando a ideia. Tudo bem. A diferença é que agora foi decisão sua, e a linha nova entra no papel.
Era o mapa, não a saída
O raio-x não te tira de lugar nenhum. Ele te diz de que tamanho é a saída, e isso decide a ordem do resto: em nome de quem tá cada conta, quem tem a senha, quanto tempo leva pra subir tudo de novo se precisar, e em que sequência se troca cada peça sem o cliente perceber. Cada uma tem seu portão. A primeira é ver o mapa inteiro, e você acabou de ver.
Fontes
- Pesquisa de mercado deste blog, "Vibe coding 2025-2026" (a pergunta "consigo sair desta plataforma?" e a distinção entre lock-in de código e de operação; síntese de relatos, não estatística)
- Supabase Docs, "Can't access Supabase project when using Lovable Cloud" (banco não pertence à sua conta, sem chave de serviço, sem transferência automática, Cloud não pode ser desconectado): https://supabase.com/docs/guides/troubleshooting/cant-access-supabase-project-lovable-cloud
- Lovable Docs, "AI" (IA embutida sempre roda pela Lovable e cobra créditos do espaço de trabalho): https://docs.lovable.dev/integrations/ai
- Lovable Docs, "Supabase" (Cloud ligado por padrão; opção de conectar um Supabase próprio): https://docs.lovable.dev/integrations/supabase