Refém do fornecedor de software: como contratar sem ficar preso (o checklist de código, contas e dados que decide isso)
Rafael Oliveira · · 7 min de leitura
A cena costuma ser assim. O sistema funciona há dois anos, a empresa cresceu e você precisa de uma integração nova. O fornecedor manda um orçamento 40% acima do que você esperava, com prazo de três meses. Você pensa em pedir uma segunda proposta e descobre, na mesma semana, que o código está no GitHub pessoal do desenvolvedor, o servidor roda na conta dele, o domínio foi registrado no CPF dele e o banco de dados fica em uma plataforma que você nunca acessou. Você aceita o orçamento. Não porque é justo, mas porque não existe alternativa. Quem já passou por um projeto travado sabe do que estou falando.
Esse é o lock-in de fornecedor na prática. Não é um golpe, na maioria dos casos. É o resultado de uma série de decisões pequenas que ninguém questionou na hora de contratar.
Por que a empresa vira refém do fornecedor de software
Quase nunca existe má-fé. O que existe é o caminho mais rápido. O desenvolvedor cria a conta da AWS no e-mail dele porque em dez minutos ele quer estar programando. Registra o domínio no cartão dele porque o cliente demorou para mandar o dado da empresa. Sobe o código no repositório pessoal porque nunca ninguém pediu diferente. O contrato, quando existe, fala em prazo e valor e não diz uma palavra sobre propriedade intelectual.
Do lado do cliente, a pergunta não é feita porque ele não sabe que precisa fazer. Ele está preocupado com o preço e com a entrega, e o sistema funcionando parece prova de que tudo está certo. A dependência cresce em silêncio, camada por camada, e só aparece no dia em que a relação precisa mudar: reajuste, troca de fornecedor, venda da empresa, auditoria de um investidor.
As 4 camadas de dependência (e quanto custa sair de cada uma)
Não existe resposta única, mas existe conta certa. Para fazer a sua, vale separar a dependência em camadas, porque cada uma tem um custo de saída diferente.
1. Código e propriedade intelectual
A pergunta é simples: se o fornecedor sumir amanhã, você tem o código-fonte completo e o direito de usá-lo? Se o repositório está em uma conta que não é da empresa, ou se o contrato não transfere a propriedade, a resposta é não. Sem código, a única saída é reconstruir. Para um sistema de gestão de porte médio, isso fica entre R$ 60 mil e R$ 300 mil e de três a oito meses, dependendo da complexidade do que já existia.
2. Infraestrutura e contas
Cloud, domínio, contas da App Store e do Google Play, serviços de e-mail transacional, gateway de pagamento. Cada conta fora do CNPJ da empresa é um ponto de bloqueio. O caso mais caro aqui é a loja de aplicativos: um app publicado na conta de desenvolvedor de terceiro pode ser transferido, mas o processo depende da cooperação dele e leva semanas. Migrar um conjunto completo de contas com cooperação do fornecedor custa entre 20 e 60 horas de trabalho técnico. Sem cooperação, pode significar republicar o app do zero e perder o histórico de avaliações e downloads.
3. Dados
Ter o sistema sem ter os dados não resolve nada. Isso vale para software sob medida e vale ainda mais para SaaS. A pergunta é: consigo exportar tudo, em um formato aberto, sem depender de ninguém? Se o banco é um Postgres ou MySQL em uma conta sua, a resposta é sim. Se os dados vivem dentro de uma plataforma proprietária que só oferece relatórios em PDF, você tem um problema que nenhum contrato resolve depois.
4. Conhecimento e operação
Essa é a camada que mais gente esquece. Mesmo com código, contas e dados em mãos, um novo time precisa saber como o sistema sobe, como faz deploy, quais variáveis de ambiente existem, o que acontece toda madrugada no job de fechamento. Sem documentação mínima, um dev novo gasta entre 40 e 120 horas só para entender o que está rodando antes de tocar em qualquer linha. Isso é dinheiro que o fornecedor original não cobra, mas o próximo cobra.
Tecnologia proprietária: o barato que sai caro
Existe uma quinta camada que merece um alerta separado: a escolha da tecnologia em si. O barato que sai caro aqui é o seguinte: uma plataforma fechada, um construtor no-code pouco conhecido ou um framework que só o fornecedor domina fazem o primeiro projeto sair mais rápido e mais barato. O custo aparece quando você precisa de outra pessoa para mexer. Se o mercado brasileiro tem poucos profissionais que conhecem aquela ferramenta, você não está preso ao fornecedor por contrato. Está preso por falta de gente.
Isso não significa que toda dependência é ruim. No Revo App, nosso produto de eventos com mais de 40 mil usuários, usamos Supabase como backend. Existe dependência ali, e escolhemos aceitá-la de olhos abertos: por baixo é um Postgres comum, com exportação completa, e a base de desenvolvedores que conhece a stack é grande. A diferença entre lock-in aceitável e lock-in perigoso é essa: você sabe qual é a porta de saída e quanto ela custa antes de entrar.
SaaS pronto também prende, só que de outro jeito
Seria desonesto dizer que o problema é exclusivo do software sob medida. Um SaaS pronto tem lock-in próprio: os dados ficam na plataforma, o preço reajusta quando ele quer, e uma funcionalidade que você depende pode ser descontinuada. A diferença é que o SaaS costuma ter exportação padronizada e um mercado inteiro de ferramentas de migração. Para operação padrão, sem processo que diferencie a empresa, o SaaS continua sendo a resposta certa, e a dependência dele é administrável.
Software sob medida faz sentido quando o processo é o seu diferencial. Nesse caso, o lock-in do fornecedor não é um detalhe: é o risco principal do projeto, e precisa ser tratado no contrato, não depois.
As 7 perguntas para fazer antes de assinar
Antes de assinar qualquer contrato, pergunta isso:
- O código vai ficar em um repositório na conta da minha empresa desde o primeiro commit? A resposta certa é sim, com você como proprietário e o fornecedor como colaborador. O contrário é sinal amarelo.
- O contrato transfere a propriedade intelectual do código para a minha empresa após o pagamento? Precisa estar escrito. Bibliotecas de terceiros e código reutilizável do fornecedor podem ficar de fora, desde que isso esteja listado.
- Cloud, domínio, lojas de aplicativo e serviços serão criados no CNPJ da empresa? O cartão de crédito é seu, o e-mail administrador é seu. O fornecedor recebe acesso, não posse.
- Como eu exporto todos os dados, em qual formato, e consigo fazer isso sozinho? Peça para ver o processo funcionando antes de assinar.
- Qual documentação vem junto com a entrega? O mínimo aceitável é um guia de instalação, o passo a passo do deploy, a lista de variáveis de ambiente e a descrição dos processos automáticos.
- Quantos desenvolvedores no Brasil conhecem essa tecnologia? Se a resposta é vaga, pergunte por que ela foi escolhida em vez de uma opção mais comum.
- O que acontece se a gente encerrar o contrato? Deve existir um período de transição definido, com entrega de acessos e uma passagem de conhecimento com hora contada.
Se o fornecedor responde as sete sem desconforto, a chance de problema cai bastante. Se ele se irrita com a pergunta um ou a dois, você já aprendeu o que precisava.
Como a OCA lida com isso na prática
Esse é o tipo de projeto que a gente constrói, e a estrutura anti-lock-in faz parte da entrega, não do adicional. Repositório na organização do cliente, contas de infraestrutura no CNPJ dele, banco de dados em Postgres com exportação direta e um README que permite a outro time subir o ambiente sem ligar para a gente. Fazemos isso porque é assim que operamos nossos próprios produtos, e porque um cliente que pode sair e não sai é uma relação melhor do que um cliente que não pode sair.
No sistema de Gestão para Imobiliárias que está em produção hoje, o cliente tem acesso administrativo a tudo: código, cloud, dados. Ele continua com a gente na manutenção por escolha, e é nesse cenário que a conversa sobre reajuste e evolução acontece sem pressão de nenhum lado. Outros projetos com a mesma estrutura estão em nosso portfólio de projetos.
O próximo passo
Se você já tem um sistema rodando, a ação gratuita é esta: mande as sete perguntas acima para o seu fornecedor atual esta semana, por escrito. A resposta, ou a ausência dela, vai dizer em qual das quatro camadas você está exposto. Faça isso antes de precisar, porque a negociação no dia da crise é sempre pior.
Se você está começando um projeto novo e quer contratar com essas garantias já no contrato, a gente pode conversar sobre o escopo e mostrar como estruturamos a entrega.
