Vendor lock-in: como não ficar refém do fornecedor

Vendor lock-in é a situação em que trocar de fornecedor custa mais caro que aguentar um fornecedor ruim. Ele quase nunca é criado por má-fé: aparece por omissão, um acesso de cada vez, até o dia em que a empresa descobre que o servidor está no cartão pessoal de alguém que não trabalha mais lá. Existem três travas, e você precisa destravar as três.

Trava 1: o código não é seu

A primeira dependência é jurídica. No Brasil, software é protegido por direito autoral, e os direitos patrimoniais pertencem a quem desenvolveu, a menos que o contrato transfira. Sem cláusula de cessão, você pagou por um sistema que legalmente não é seu.

O que exigir por escrito:

• Cessão total e definitiva dos direitos patrimoniais sobre o que foi desenvolvido para você, sem limite de tempo ou território.
• Entrega contínua do código, não apenas no fim. O repositório deve estar em conta da sua empresa desde o primeiro commit.
• Declaração sobre bibliotecas de terceiros: quais componentes open source foram usados e sob quais licenças. Uma licença copyleft mal escolhida pode contaminar a distribuição do seu produto.
• Exceção nomeada para componentes reutilizáveis do fornecedor, se houver. É legítimo que um estúdio tenha bibliotecas próprias reaproveitadas entre clientes, mas você precisa saber quais são e receber licença perpétua de uso delas.

Trava 2: os dados não saem

A segunda dependência é a mais silenciosa. Mesmo com o código na mão, se você não consegue extrair os dados em formato utilizável, migrar é reconstruir do zero.

Exija:

• Acesso direto ao banco de dados em ambiente de produção, com credenciais próprias e permissão de leitura no mínimo.
• Dump completo sob demanda, em formato padrão (SQL, CSV ou JSON), sem custo adicional e sem prazo maior que alguns dias úteis.
• Documentação do modelo de dados: o que cada tabela guarda e como se relacionam. Um banco sem esse mapa é um arquivo criptografado por obscuridade.
• Backups em armazenamento seu, não só no do fornecedor. Um bucket na sua conta recebendo cópia diária custa alguns reais por mês e elimina uma categoria inteira de risco.

Atenção especial a sistemas em plataformas no-code e SaaS: muitos exportam apenas parte do que você criou. Automações, regras e lógica de fluxo costumam ficar dentro da ferramenta e não vêm no export. Teste a exportação antes de construir seis meses de processo lá dentro.

Trava 3: você não controla os acessos

A terceira dependência é operacional e a mais comum. O sistema funciona, o código é seu, os dados saem, mas o domínio está no CPF do desenvolvedor e a chave da API de pagamento foi criada com o Gmail pessoal dele.

Faça o inventário e corrija cada linha:

A regra é simples: o fornecedor deve ser convidado nas suas contas, nunca o contrário. Isso torna a saída dele uma remoção de acesso, e não uma negociação.

O teste do ônibus, aplicado a fornecedores

Uma vez por trimestre, faça a pergunta: se este fornecedor parasse de atender hoje, quanto tempo levaria para outro time colocar o sistema no ar?

Para responder de verdade, teste em vez de supor:

1. Clone o repositório com suas próprias credenciais.
2. Peça um dump do banco e confira se ele abre.
3. Localize onde estão documentadas as variáveis de ambiente.
4. Verifique se você consegue entrar sozinho no painel do servidor.

Se qualquer um dos quatro passos travar, você encontrou o lock-in antes que ele te encontrasse.

O que é dependência legítima e o que não é

Nem toda dependência é problema. Depender do conhecimento acumulado de um time bom é natural e até desejável, trocar de fornecedor sempre custa curva de aprendizado. O que não é aceitável é dependência artificial, criada por retenção de ativos que você pagou para ter.

A distinção prática:

• Legítimo: o fornecedor conhece o histórico das decisões e resolve problemas mais rápido que qualquer substituto.
• Ilegítimo: só o fornecedor consegue publicar uma nova versão porque só ele tem a senha.

Um fornecedor que se sustenta pelo primeiro tipo não tem medo de entregar acessos. Fornecedores que dependem do segundo criam obstáculo quando você pede, e essa reação, por si só, é a informação que você precisava.

A cláusula mínima para colocar no contrato

Se você levar apenas uma coisa deste texto para o seu contrato, leve esta ideia em três partes:

1. Todo código produzido sob este contrato tem seus direitos patrimoniais cedidos ao contratante, de forma total e definitiva.
2. Repositório, ambiente de produção, banco de dados, domínio e credenciais de terceiros permanecem em contas de titularidade do contratante durante e após a vigência.
3. Ao término, o contratado entrega em até 10 dias úteis dump do banco, documentação de publicação e transferência formal de todos os acessos, sem custo adicional.

Três parágrafos. É o que separa trocar de parceiro de recomeçar do zero.