Refém do fornecedor de software: como escolher tecnologia sem ficar preso a quem desenvolveu seu sistema
Rafael Oliveira · · 6 min de leitura
A cena se repete com frequência: a empresa contratou um sistema há três anos, ele funciona, mas qualquer alteração precisa passar pelo fornecedor original. O orçamento de uma mudança simples vem alto e demora. A empresa pensa em trocar de fornecedor e descobre que não tem acesso ao código, não sabe onde o sistema está hospedado, e o banco de dados está em um formato que só a ferramenta proprietária do fornecedor lê. Trocar significaria começar do zero. Então a empresa paga o orçamento alto e segue refém.
Quem já passou por um projeto travado sabe do que estou falando. Isso tem nome: vendor lock-in, a dependência estrutural de um fornecedor específico. E o detalhe importante é que o lock-in quase nunca nasce de má fé. Ele nasce de decisões que ninguém questionou na hora da contratação, porque o cliente não sabia o que perguntar.
Como o lock-in acontece na prática
Na minha experiência herdando sistemas que outros times abandonaram, o aprisionamento aparece em quatro camadas. Vale conhecer cada uma, porque elas se somam.
1. Código sem acesso ou sem propriedade
A mais óbvia e a mais comum. O contrato não define de quem é o código, ou define que é do fornecedor. Sem o código-fonte e sem a cessão de direitos formalizada, qualquer outro profissional que você contratar terá que reconstruir o sistema, não evoluir.
2. Infraestrutura na conta do fornecedor
O sistema roda em um servidor que o fornecedor paga e administra. O domínio está registrado no CPF do dono da agência. As chaves de API do gateway de pagamento estão em uma conta que você nunca viu. Se a relação azedar, você não tem nem como fazer backup.
3. Tecnologia obscura ou fora de mercado
Sistemas construídos em frameworks proprietários, plataformas low-code fechadas ou linguagens que quase ninguém usa no Brasil. Mesmo com o código em mãos, você não encontra profissional disponível para dar manutenção, ou encontra por um preço que inviabiliza a troca.
4. Conhecimento que só existe na cabeça de uma pessoa
Zero documentação, zero histórico de decisões, banco de dados sem dicionário. O sistema até usa tecnologia comum, mas entender como ele funciona por dentro exige semanas de engenharia reversa. O barato que sai caro aqui é o seguinte: o fornecedor que cobrou menos na proposta provavelmente economizou exatamente nessas entregas invisíveis.
O que o lock-in custa em reais
Dependência de fornecedor não é um problema abstrato, é uma linha de custo. Ela aparece de três formas:
- Sobrepreço em manutenção. Sem concorrência possível, o fornecedor precifica como quer. Alterações que valeriam R$ 2.000 a R$ 4.000 no mercado chegam a R$ 10.000 ou mais, porque a alternativa do cliente é nenhuma.
- Custo de migração forçada. Quando a relação rompe, reconstruir um sistema de médio porte custa entre R$ 60.000 e R$ 250.000 e leva de 3 a 8 meses, dependendo da complexidade. É pagar de novo por algo que você já pagou.
- Custo de oportunidade. O mais difícil de medir e o mais caro. Cada melhoria que a empresa deixa de fazer porque o orçamento veio alto demais é receita ou eficiência que ficou na mesa.
Não existe resposta única, mas existe conta certa: se o custo anual de manter o fornecedor atual está acima de 25% a 30% do que custaria reconstruir, a dependência já virou prejuízo estrutural.
As perguntas que evitam o problema antes do contrato
Antes de assinar qualquer contrato, pergunta isso:
- De quem é o código depois do pagamento? A resposta certa é: seu, com cessão de direitos por escrito no contrato. Acesso ao repositório (GitHub, GitLab) em uma organização que pertence à sua empresa, não ao fornecedor.
- Em nome de quem ficam as contas de infraestrutura? Servidor, domínio, banco de dados, gateway de pagamento, tudo em contas da sua empresa. O fornecedor recebe acesso como colaborador, nunca como dono.
- Qual a stack e quantos profissionais no Brasil trabalham com ela? Você não precisa entender de tecnologia para fazer essa pergunta. Peça os nomes das linguagens e frameworks e pesquise vagas com esses termos no LinkedIn. React, Node.js, Python, Flutter: milhares de profissionais. Framework proprietário da agência: você já sabe a resposta.
- O que é entregue além do sistema funcionando? Documentação de arquitetura, instruções de instalação, dicionário do banco de dados. Não precisa ser um livro, precisa permitir que outro dev competente assuma em dias, não em meses.
- Como funciona a saída? Um fornecedor sério aceita colocar no contrato uma cláusula de transição: em caso de encerramento, ele entrega acessos, código atualizado e um período de suporte à passagem de bastão. Quem se recusa a discutir a própria saída está dizendo algo sobre o modelo de negócio dele.
Um teste simples para sistemas que já existem
Se você já tem um sistema rodando, faça este exercício hoje: consegue listar onde ele está hospedado, quem tem acesso ao código e quanto custaria para outro profissional assumir? Se qualquer uma dessas respostas for "não sei", você tem lock-in em algum grau. Melhor descobrir agora, com a relação saudável, do que em uma crise.
Low-code e plataformas prontas: o lock-in disfarçado de agilidade
Uma nota honesta: plataformas no-code e low-code têm o seu lugar. Para validar uma ideia ou automatizar um processo interno simples, elas entregam rápido e barato, e às vezes são a recomendação certa. Já indiquei esse caminho para clientes que não precisavam de software sob medida.
O problema é usá-las como fundação de uma operação crítica. Nessas plataformas, o lock-in não é acidente, é modelo de negócio: seus dados, sua lógica e seus fluxos vivem dentro de um produto que pode dobrar de preço, mudar de regra ou descontinuar recursos, e exportar de lá raramente é trivial. O critério prático: se o processo é experimental, plataforma pronta serve. Se o processo é o coração da empresa, você quer código que é seu, em tecnologia de mercado.
Como uma software house séria estrutura isso
Esse é o tipo de conversa que a gente tem na OCA antes de qualquer projeto. Nosso padrão é o oposto do aprisionamento: código em repositório do cliente, infraestrutura em contas do cliente, stack de mercado (React, React Native, Node.js, Next.js) com milhares de profissionais disponíveis no Brasil, e documentação que permite transição. Fazemos assim no nosso próprio produto, o Revo App, que atende mais de 40 mil usuários: se a regra vale para o que é nosso, vale para o que construímos para os outros.
Parece contraintuitivo um fornecedor facilitar a própria substituição. Na prática é o contrário: cliente que fica por escolha renova, indica e amplia o escopo. Cliente que fica por falta de opção sai na primeira oportunidade e leva junto a reputação do fornecedor. Boa parte dos projetos que chegam até nós são exatamente resgates de sistemas presos, e dá para ver no portfólio de projetos da OCA que sistemas de operação real, como gestão de imobiliárias e ticketing, rodam nesse modelo aberto.
O próximo passo prático
Se você vai contratar um sistema, leve as cinco perguntas acima para a reunião com cada fornecedor e anote as respostas por escrito. A comparação entre elas costuma decidir a escolha melhor do que qualquer portfólio. Se você já está preso a um fornecedor e quer entender o tamanho do problema e as opções de saída, a gente avalia o cenário sem compromisso.
