Vendor lock-in: como escolher tecnologia sem ficar refém do fornecedor de software

A situação costuma aparecer assim: a empresa quer trocar de sistema, ou só quer que outro time faça uma melhoria, e descobre que não pode. O código pertence ao fornecedor. O banco de dados está num formato que só a plataforma dele lê. Exportar os dados custa uma taxa que ninguém viu no contrato. Migrar significa recomeçar do zero. Nesse momento, a mensalidade sobe, o suporte piora, e a empresa paga assim mesmo, porque a alternativa é mais cara.

Isso tem nome: vendor lock-in, o aprisionamento tecnológico. E quase nunca acontece por má-fé escancarada. Acontece porque, na hora de contratar, ninguém fez as perguntas certas. Quem já passou por um projeto travado sabe do que estou falando.

O que é vendor lock-in e por que ele custa caro

Vendor lock-in é qualquer situação em que sair de um fornecedor custa tão caro, em dinheiro, tempo ou risco, que a empresa fica presa mesmo insatisfeita. O custo raramente aparece na proposta comercial. Ele aparece depois, em três formas:

• Custo de migração. Reescrever integrações, reconstruir telas, treinar equipe de novo. Em sistemas de operação, isso facilmente passa de R$ 50 mil e de 3 meses de trabalho.
• Perda de poder de negociação. Quando o fornecedor sabe que você não consegue sair, o reajuste anual vira comunicado, não conversa.
• Risco de continuidade. Se o fornecedor quebrar, for vendido ou descontinuar o produto, sua operação vai junto. Já vi empresa perder histórico de 6 anos de pedidos porque a plataforma encerrou e o formato de exportação era proprietário.

O barato que sai caro aqui é o seguinte: a proposta com mensalidade menor muitas vezes é a que embute o aprisionamento mais profundo. O fornecedor pode cobrar pouco na entrada porque sabe que vai recuperar na permanência forçada.

As 4 portas por onde o aprisionamento entra

1. Propriedade do código

Em software sob medida, a pergunta central é: o código-fonte é seu ou do fornecedor? Se o contrato não diz explicitamente que a propriedade intelectual é transferida ao cliente, na prática ela fica com quem escreveu. Resultado: você pagou pelo desenvolvimento, mas só pode mexer no sistema pagando de novo para a mesma empresa.

2. Formato e acesso aos dados

Seus dados podem estar tecnicamente acessíveis e ainda assim presos. Um banco em formato proprietário, sem exportação estruturada (CSV, JSON, dump SQL), é uma jaula. Pergunte sempre: se eu quiser todos os meus dados amanhã, em formato aberto, como recebo e quanto custa? Se a resposta for vaga, o preço é alto.

3. Tecnologia sem mercado

Existe lock-in de fornecedor e existe lock-in de tecnologia. Um sistema escrito numa linguagem ou plataforma que poucos profissionais dominam no Brasil prende você quase tanto quanto um contrato ruim, porque só o fornecedor original consegue mantê-lo a um custo razoável. Stacks com mercado amplo, como Node.js, React, PostgreSQL, garantem que dezenas de milhares de devs no país conseguem assumir o projeto.

4. Infraestrutura na conta do fornecedor

Se o servidor, o domínio e os serviços de nuvem estão na conta do fornecedor, e não na sua, trocar de parceiro exige a boa vontade dele para transferir tudo. Nas separações amigáveis, funciona. Nas litigiosas, vira refém de novo. A infraestrutura deve estar em contas da sua empresa desde o dia um, com o fornecedor operando como colaborador convidado.

Checklist: as 7 perguntas antes de assinar qualquer contrato

Antes de assinar qualquer contrato, pergunta isso:

1. O código-fonte é meu? A cláusula de propriedade intelectual transfere o código ao cliente após o pagamento? Onde fica o repositório e eu tenho acesso de administrador?
2. Consigo exportar todos os meus dados? Em que formato, com que frequência, a que custo? Isso está escrito no contrato?
3. Qual é a stack e quantos profissionais a dominam no Brasil? Se a resposta envolver uma plataforma que só o fornecedor conhece, desconfie.
4. A infraestrutura fica em contas da minha empresa? Nuvem, domínio, serviços de e-mail, gateways de pagamento: tudo no CNPJ do cliente.
5. Existe documentação suficiente para outro time assumir? Peça para ver um exemplo de documentação de projeto anterior.
6. O que acontece se encerrarmos o contrato? Prazo de transição, entrega de credenciais, apoio na migração: quanto mais detalhado, mais confiável o fornecedor.
7. Há multa ou fidelidade que me prenda além do razoável? Fidelidade de 12 meses em contrato de manutenção é comum. Fidelidade de 36 meses com multa integral é sinal de alerta.

Um fornecedor sério responde essas sete perguntas sem desconforto. Quem se irrita com a pergunta 1 ou enrola na pergunta 2 está dizendo, na prática, qual é o modelo de negócio dele.

SaaS pronto também prende, só que de outro jeito

Não existe resposta única, mas existe conta certa. Assinar um SaaS pronto muitas vezes é a decisão correta, e digo isso mesmo vendendo software sob medida: para CRM genérico, contabilidade ou RH, um SaaS consolidado quase sempre ganha. Mas o lock-in existe lá também, em outra forma:

• Você nunca será dono do código, por definição. Isso é aceitável, desde que os dados sejam exportáveis.
• O roadmap é do fornecedor. Se a funcionalidade que sua operação precisa não interessa aos outros 10 mil clientes, ela não vai existir.
• Reajustes de preço em dólar, comuns em ferramentas gringas, podem dobrar o custo anual sem você mudar nada no uso.

O critério de decisão é simples: quanto mais o processo é uma vantagem competitiva sua, e não uma commodity, mais faz sentido ter software próprio, com código seu e dados seus. Quanto mais o processo é igual ao de qualquer empresa, mais faz sentido alugar o SaaS e aceitar o lock-in leve que vem junto.

Como a gente lida com isso na prática

Na OCA, esse checklist não é teoria de artigo, é o padrão dos nossos contratos. O código-fonte fica no repositório do cliente, com propriedade transferida. A infraestrutura roda em contas do cliente. E usamos stacks com mercado amplo, React Native, Next.js, Node.js, PostgreSQL, justamente para que qualquer time sênior consiga assumir o projeto amanhã, se o cliente quiser.

Parece contraintuitivo um fornecedor facilitar a própria substituição. Mas a nossa aposta é a inversa: cliente que fica porque quer renova por anos; cliente que fica porque não consegue sair, sai na primeira brecha e ainda fala mal. Nossos projetos em produção, do sistema de gestão para imobiliárias aos produtos próprios como o Revo App, seguem esse mesmo desenho: dados exportáveis, código versionado, infraestrutura nomeada ao dono.

Esse é o tipo de projeto que a gente constrói: sistemas que pertencem a quem paga por eles.

O próximo passo

Se você está avaliando propostas agora, faça o exercício antes de qualquer reunião: envie as 7 perguntas do checklist por e-mail aos fornecedores finalistas e compare as respostas por escrito. A diferença de postura entre quem responde direto e quem desconversa costuma decidir a escolha sozinha.

E se você quer conversar sobre um sistema sob medida desenhado desde o início para não te prender, converse com a OCA sobre o seu sistema. A primeira conversa serve justamente para responder, sobre o nosso próprio trabalho, as mesmas perguntas que este artigo te ensinou a fazer.