Vendor lock-in: quanto custa e quando vale a pena aceitar

Vendor lock-in não é um defeito a ser evitado. Toda ferramenta que você adota vende velocidade hoje em troca de opcionalidade amanhã, e o trabalho é precificar essa troca antes de assinar.

Um founder de logística com quem trabalhamos tinha construído todo o portal de operações da empresa em uma plataforma no-code. Seis semanas de trabalho, e aquilo rodou o negócio muito bem por dois anos. Então o maior prospect dele colocou single sign-on e um log de auditoria exportável no contrato, como condição para assinar. A plataforma não fazia nem uma coisa nem outra. Reconstruir levou cinco meses, e o cliente não esperou.

Vendor lock-in é a condição de depender tanto de um fornecedor que sair custa mais do que ficar, mesmo quando ficar é a coisa errada a fazer. Não é um defeito escondido em ferramentas ruins. É o subproduto natural de qualquer ferramenta que faz trabalho de verdade por você, e ele se acumula em quatro lugares: no seu código, nos seus dados, nos seus fluxos de trabalho e nas suas pessoas.

Aquele founder não ficou preso porque tomou uma decisão ruim. Ele ficou preso porque tomou uma boa decisão e nunca mais voltou para conferir o preço dela.

O que vendor lock-in realmente significa

A definição de manual fala de custo de troca: formatos proprietários, APIs incompatíveis, multas contratuais, a despesa de migrar de um fornecedor para outro. Essa definição está correta e é quase inútil, porque descreve uma condição que se aplica literalmente a toda ferramenta que você vai adotar na vida.

A distinção útil é outra.

Você não está preso quando sair é caro. Você está preso quando sair é caro o suficiente para você parar de considerar a hipótese.

É essa a linha que importa. Custo de troca é um número. Lock-in é o que acontece quando o número fica grande o bastante para começar a tomar decisões no seu lugar: quando você para de avaliar alternativas, quando contorna uma funcionalidade que falta em vez de exigi-la, quando diz não para um cliente porque a sua plataforma disse não primeiro. O founder de logística não decidiu perder aquele contrato. A stack dele decidiu por ele, dois anos antes, numa terça-feira, quando ninguém estava prestando atenção.

As quatro travas

Lock-in costuma ser discutido como se fosse uma coisa só. São quatro, e têm preços muito diferentes.

Trava de código. Você não consegue levar o software embora, porque não existe software para levar. Plataformas no-code são o caso mais puro: não há artefato, não há repositório, não há nada que rode em lugar nenhum fora do editor do fornecedor. Linguagens proprietárias são a mesma armadilha de terno e gravata. No momento em que a sua lógica passa a viver num dialeto que só uma empresa compila, essa lógica é dela.

Trava de dados. Toda plataforma do mundo exporta os seus dados. Quase nenhuma exporta o formato deles. Você recebe um CSV de clientes e perde as relações entre eles, o modelo de permissões, a máquina de estados pela qual os pedidos passam, os IDs que outros três sistemas referenciam. As linhas sobrevivem. O sentido, não.

Trava de processo. Essa é a que ninguém precifica, e costuma ser a mais cara. Ao longo de dois anos, o seu time remodela silenciosamente o negócio para caber nas premissas da ferramenta. Alguém inventa um passo manual porque a plataforma não dá conta de um passo de verdade. O passo vira hábito, o hábito vira processo, e o processo vira o jeito como a empresa funciona. Agora você não está migrando um software. Está migrando uma organização.

Trava de pessoas. As únicas pessoas capazes de manter aquilo são certificadas no ecossistema do fornecedor, o que significa que você contrata de um mercado de trabalho que o fornecedor controla, a um preço que o fornecedor influencia. Quando o seu único desenvolvedor certificado pede as contas, você não vai ao mercado. Vai ao diretório de parceiros do fornecedor.

A trava de código é a mais barulhenta e a mais fácil de resolver. As travas de processo e de pessoas são silenciosas, acumulam juros todo dia, e são as que de fato prendem empresas.

Lock-in é um preço, não um defeito

Aqui está a parte que o resto da internet erra.

Toda abstração que você adota te prende. Postgres te prende. React te prende. O seu sistema contábil, o seu provedor de folha de pagamento, a linguagem em que o seu produto é escrito, a nuvem onde os seus servidores rodam. O único jeito de ter zero dependências é construir tudo sozinho, o que é outra armadilha, e bem pior.

Então a pergunta nunca é “estou preso?”. Você está. A pergunta é quanto você pagou, e se o que você comprou vale isso.

Joel Spolsky traçou essa linha há vinte e cinco anos em In Defense of Not-Invented-Here Syndrome, e ela não se moveu desde então:

Se é uma função central do negócio — faça você mesmo, custe o que custar.

É esse o framework inteiro, e ele se converte com precisão numa regra sobre dependências. Lock-in numa função que não gera dinheiro é barato, e você deveria abraçá-lo. Você não quer ser dono do seu sistema de folha de pagamento. Fique preso ao fornecedor e durma bem. Lock-in no sistema de que a sua margem depende é existencial, e nenhum desconto é grande o bastante para justificar. Se o seu motor de precificação, o seu algoritmo de matching ou a sua lógica de crédito moram dentro do produto de outra empresa, você não está tocando uma empresa. Está tocando uma franquia.

A maioria dos founders faz isso ao contrário. Agoniza por semanas sobre qual CRM comprar, uma decisão reversível em três semanas, e então deixa casualmente que aquilo que os diferencia seja construído dentro de uma plataforma da qual nunca vão escapar. A decisão entre build e buy não é sobre custo. É sobre de que lado dessa linha o sistema está.

O teste do custo de saída

Antes de adotar qualquer coisa que vá encostar num fluxo central, rodamos quatro perguntas. Leva vinte minutos e é o seguro mais barato que existe em software.

1. Se sairmos daqui a dezoito meses, o que fisicamente vem com a gente?

Diga os artefatos em voz alta: código-fonte, schema do banco, dados, documentação, domínio, cadastro de clientes, integrações. Escreva a lista. Se a resposta honesta for “um CSV”, você não é cliente. É inquilino.

2. Quantas semanas, e não quantos reais?

Precifique a saída em semanas de engenharia e em interrupção do negócio, nunca em mensalidade de licença. Dinheiro se recupera. Uma reconstrução de cinco meses que cai no meio de uma rodada, não. O custo de saída do founder de logística não era um número numa fatura. Era um trimestre e um logo de peso.

3. O nosso roadmap precisa da autorização do roadmap deles?

Essa é a mais afiada das quatro. Se você não consegue lançar uma funcionalidade que te diferencia até o fornecedor decidir construí-la, você não comprou uma ferramenta. Terceirizou a sua estratégia de produto para uma empresa que nunca conversou com os seus clientes e não se importa se você vence.

4. Quem mais consegue manter isso?

Se a resposta for “parceiros certificados do fornecedor”, você tem um problema de oferta disfarçado de escolha técnica. Se a resposta for “qualquer engenheiro competente que conheça essa linguagem”, está tudo bem.

Pontue as quatro com honestidade. Uma ferramenta que reprova nas perguntas 1 e 3 é excelente para validação e perigosa como arquitetura. Isso não é contradição. É cronograma.

Onde founders realmente ficam presos

Pesquise vendor lock-in e você vai encontrar dez artigos sobre taxas de saída da AWS e estratégia multicloud. Úteis, se você tem um departamento de TI. Não é ali que o problema morde um founder. É aqui.

A plataforma no-code que você superou. Ela te levou a um produto funcionando em seis semanas, o que foi a escolha certa. Ela não faz SSO, log de auditoria, um modelo de permissões de verdade, nem o único fluxo que o seu cliente corporativo exige. A maioria dos founders fica no no-code de seis a doze meses a mais do que deveria, e essa demora não é uma falha de tecnologia. É a falha de nunca ter relido a etiqueta de preço depois que a empresa mudou.

A software house que guarda o seu repositório. Essa é a que mata empresas, e quase sempre é descoberta no pior momento possível. Se o seu contrato de desenvolvimento de software não diz que o código é seu, num repositório que você controla, desde o primeiro dia, então você não tem um parceiro de tecnologia. Tem um locador. O source code escrow existe justamente porque isso acontece com frequência suficiente para ter gerado o próprio instrumento jurídico.

O modelo de dados entortado em volta de um único fornecedor. Alguém usou os IDs de um provedor de pagamento como chave primária. Alguém guardou o estado de um pedido num campo que só aquele provedor escreve. Dois anos depois, trocar de adquirente significa reescrever o sistema de pedidos, e o sistema de pedidos é a empresa.

A ferramenta interna que ninguém documentou. Um prestador construiu, um prestador entendia, e esse prestador foi embora. Agora você não está preso a um fornecedor. Está preso a um sistema legado com zero pessoas no quadro.

Quando o lock-in é a troca certa

Com frequência. Mais do que os artigos alarmistas sugerem.

Quando você ainda está validando. Se a empresa pode não existir daqui a um ano, opcionalidade é artigo de luxo que você não tem como pagar. Fique preso, lance em seis semanas e descubra se alguém quer aquilo. Opcionalidade que você nunca exerce é dinheiro queimado.

Quando a função não é central. Folha de pagamento, e-mail, contabilidade, o CRM do seu time comercial de seis pessoas. Adote o líder de mercado, fique preso e nunca mais pense no assunto. O custo mental de se manter portátil numa commodity já é, por si só, um custo.

Quando a saída é genuinamente reversível. Se dá para sair em menos de quatro semanas, aquilo não é lock-in. É custo de troca, e custo de troca é normal.

O que nos dá a regra prática que usamos, e a única frase deste artigo que vale escrever no quadro branco:

Aceite lock-in na proporção inversa da proximidade entre o sistema e a sua margem.

Quanto mais longe do dinheiro um sistema estiver, mais lock-in você deveria aceitar de bom grado. Quanto mais perto ele chegar, mais você deveria ser dono. Quase todo erro caro que somos chamados para consertar é uma violação dessa única linha.

Como evitar vendor lock-in sem virar paranoico

A falha oposta existe, e é mais comum entre times técnicos do que entre founders: construir camadas de abstração “por precaução”, escrever o próprio wrapper em volta de cada serviço, recusar infraestrutura gerenciada porque um dia talvez você mude. Isso é um imposto de portabilidade, e você paga todo santo dia por uma migração que provavelmente nunca vai acontecer. O custo da portabilidade prematura é um aluguel. O custo de uma migração é um financiamento. Aluguel é pior.

A versão proporcional é curta.

Seja dono do repositório, desde o primeiro dia, numa conta que você controla. Seja dono do seu modelo de dados, e entenda-o bem o suficiente para descrevê-lo em uma frase. Seja dono do domínio e do DNS. Exporte seus dados todo mês e, pelo menos uma vez, restaure o export de verdade em outro lugar. Um export que você nunca restaurou não é um backup. É uma crença.

Depois coloque no contrato: propriedade do código desde o primeiro dia, cláusula de portabilidade de dados, e documentação como entregável nomeado, não como favor.

Os reguladores começaram a tratar custo de troca como problema de concorrência, e não como inconveniente técnico. O Data Act da União Europeia, em aplicação desde setembro de 2025, estabelece um arcabouço que obriga provedores de serviços de processamento de dados a permitir que clientes troquem de fornecedor, e proíbe cláusulas contratuais que bloqueiem o compartilhamento de dados. A direção é clara: o direito de sair está virando algo que lhe é devido, não algo que você negocia. É uma boa notícia, e vai chegar tarde demais para ajudar você com o fornecedor que está escolhendo neste trimestre.

Perguntas frequentes

O que é vendor lock-in, em termos simples?

Depender tanto de um único fornecedor que trocar custaria mais do que ficar, mesmo quando ficar está machucando você. O custo pode estar no código que você não consegue levar, nos dados que não consegue exportar de forma útil, nos processos construídos em volta dos limites da ferramenta, ou nas pessoas que só conhecem o ecossistema daquele fornecedor.

Qual é um exemplo de vendor lock-in?

Uma startup constrói seu portal de operações numa plataforma no-code. Dois anos depois, um cliente corporativo exige single sign-on e log de auditoria. A plataforma não entrega nenhum dos dois, não há código-fonte para modificar, e o único caminho adiante é uma reconstrução de cinco meses. O custo de troca era invisível no dia um e decisivo no dia setecentos.

Como evitar vendor lock-in?

Você não evita. Você precifica. Antes de adotar uma ferramenta, pergunte o que fisicamente sai com você se você for embora, quantas semanas a saída levaria, se o seu roadmap depende do roadmap do fornecedor, e quem além dos parceiros dele consegue manter aquilo. Depois seja dono do repositório, do modelo de dados e do domínio, e teste os seus exports.

Vendor lock-in é sempre ruim?

Não. Lock-in numa função commodity é uma boa troca e normalmente uma pechincha. Lock-in no sistema que produz a sua margem é um erro estratégico. A distância entre o sistema e a sua receita é o que determina qual dos dois você está olhando.

O founder de logística reconstruiu o portal. Cinco meses, e perdeu o cliente. Quando perguntamos o que faria diferente, ele não disse que teria evitado a plataforma no-code. Disse que teria escrito num papel, no dia em que a adotou, quanto custaria sair.

Ele nunca escreveu esse número, então ele cresceu em silêncio por dois anos, e ele só foi descobri-lo no único dia em que não dava para pagar.

O lock-in nunca foi o problema. Não saber o preço era.