Refém do fornecedor de software: como contratar um sistema sem perder o controle do código, dos dados e dos acessos (o checklist de saída de 2026)

O sistema funciona. O fornecedor atende. Às vezes demora, mas atende. Um dia você pede o orçamento de uma mudança simples e recebe um número que não faz sentido. Você pensa em chamar outra empresa e aí descobre o problema: o código está no repositório do fornecedor, o servidor está no cartão dele, o domínio está no CPF de um dos sócios e ninguém da sua equipe sabe exportar os dados do banco sem a ajuda de quem você queria trocar.

Na maioria dos casos não houve má-fé. Isso vem de decisões pequenas, tomadas no começo do projeto, quando todo mundo estava com pressa e confiando. Se hoje a sua resposta para “quanto custaria trocar de fornecedor?” é “não faço ideia”, você está mais preso do que imagina. A boa notícia: essa dependência pode ser medida e, principalmente, evitada no próximo contrato.

Por que empresas ficam reféns do fornecedor de software sem perceber

A dependência raramente nasce de uma cláusula maliciosa. Ela nasce da conveniência. No início, é mais rápido o fornecedor criar a conta na nuvem com o cartão dele e repassar o custo na fatura. É mais rápido ele mesmo registrar o domínio. É mais rápido manter o código no repositório da própria empresa dele. Ninguém documenta nada porque “a gente mesmo vai manter”.

Cada atalho desses economiza algumas horas na primeira semana e cria um custo escondido. Esse custo só aparece quando a relação muda: o fornecedor aumenta o preço, perde a pessoa que conhecia o sistema, fecha as portas ou deixa de priorizar o seu projeto. Quem já passou por um projeto travado sabe do que estou falando.

O ponto central é este: toda escolha de tecnologia tem um custo de saída. Ter dependência não é o problema. O problema é não saber quanto ela custa antes de assinar.

Os 5 níveis de dependência e quanto custa sair de cada um

Quando fazemos diagnóstico de sistema herdado, a dependência sempre aparece em cinco camadas. As faixas abaixo são de 2026, para sistemas web e aplicativos de porte pequeno a médio. Elas variam conforme o tamanho do sistema e o quanto o fornecedor atual colabora na transição.

1. Código: de quem é e onde está

Sintoma: você não tem acesso ao repositório, ou o contrato não diz de quem é o código.

Custo de saída: se o código é seu e você tem acesso, trocar de equipe custa a curva de aprendizado do time novo. Se não é, a saída é reescrever: de R$ 60 mil a R$ 250 mil e de 3 a 8 meses, dependendo do sistema.

Pergunta que previne: “O repositório fica numa conta da minha empresa desde o primeiro commit, e o contrato cede para mim os direitos sobre o código?”

2. Dados: dá para levar embora?

Sintoma: os dados só saem em relatório PDF ou em planilhas parciais. Você não sabe em que banco eles estão.

Custo de saída: com banco de mercado (PostgreSQL, MySQL) e acesso direto, a exportação leva dias. Sem acesso, alguém precisa extrair pelas telas e relatórios e reconstruir as relações entre as tabelas: de R$ 8 mil a R$ 40 mil e de 2 a 6 semanas, com risco real de perder histórico.

Pergunta que previne: “Em que banco ficam os meus dados, e eu consigo um backup completo sem depender de vocês?”

3. Infraestrutura e acessos

Sintoma: servidor, domínio, contas nas lojas de aplicativo, WhatsApp Business API, gateway de pagamento ou e-mail transacional estão no nome ou no cartão do fornecedor.

Custo de saída: levar a infraestrutura para uma conta sua custa de R$ 3 mil a R$ 15 mil e leva de 1 a 3 semanas, se o fornecedor colaborar. Se ele não colaborar, o gargalo vira o domínio e as lojas. Para transferir um app entre contas de desenvolvedor, a conta de origem precisa iniciar o processo. Sem isso, você publica um app novo e pede para todos os usuários baixarem de novo.

Pergunta que previne: “Todas as contas ficam no CNPJ da minha empresa, com vocês entrando como usuários convidados?”

4. Stack: outro time consegue assumir?

Sintoma: o sistema usa um framework interno do fornecedor, uma linguagem pouco comum ou uma plataforma proprietária que só ele opera.

Custo de saída: com tecnologia de mercado (React, Node.js, React Native, Python, Laravel), você acha outro time em 1 a 3 semanas. Com tecnologia rara, a busca leva meses, a hora sai mais cara e muitas vezes a resposta acaba sendo reescrever.

Pergunta que previne: “Se vocês saírem do projeto amanhã, quantos devs no mercado conseguem manter isso? Por que escolheram essa tecnologia?”

5. Conhecimento: está documentado ou está na cabeça de alguém?

Sintoma: só uma pessoa do fornecedor sabe publicar uma atualização. Não há README, as variáveis de ambiente não estão registradas e o deploy é manual.

Custo de saída: sem documentação, um time novo gasta de 3 a 8 semanas só entendendo o sistema antes de entregar qualquer coisa útil. São de R$ 15 mil a R$ 50 mil em horas de descoberta.

Pergunta que previne: “Um dev com acesso ao repositório consegue rodar o sistema e publicar uma versão em um dia, seguindo só a documentação?”

Nem toda dependência é ruim: quando o lock-in compensa

Seria fácil concluir que o ideal é não depender de nada. Não é. Na maioria dos casos, construir tudo do zero para fugir da dependência custa mais do que a própria dependência.

Ninguém em sã consciência constrói a própria integração com bandeiras de cartão: usa um gateway de pagamento. Também não faz sentido escrever do zero um sistema de envio de e-mail ou de autenticação quando existem serviços gerenciados que resolvem isso por algumas dezenas de reais por mês. E se o seu processo comercial é padrão, um CRM pronto de mercado provavelmente atende melhor que um sistema sob medida. Nesse caso, o custo de saída se resume a exportar os contatos.

Não existe resposta única, mas existe conta certa. A dependência compensa quando atende a três condições:

• Economiza tempo de verdade: semanas ou meses de desenvolvimento, não algumas horas.
• Tem substituto: existem concorrentes que fazem a mesma coisa, de forma parecida.
• O preço da saída é conhecido: você sabe quanto custaria trocar e esse valor cabe no seu orçamento.

Uma regra prática resume bem: depender de um serviço de mercado costuma ser aceitável. Depender de uma pessoa específica quase nunca é.

Checklist antes de assinar: 8 perguntas para fazer ao fornecedor

Antes de assinar qualquer contrato, pergunta isso:

1. O código fica em um repositório na conta da minha empresa desde o início?
2. O contrato diz, por escrito, que os direitos sobre o código e os entregáveis são meus após o pagamento?
3. Em que banco de dados ficam as informações, e como eu faço um backup completo sozinho?
4. Servidor, domínio, lojas de aplicativo e contas de serviços externos estarão no meu CNPJ?
5. Que tecnologia vocês vão usar, e quão fácil é contratar outro dev que a conheça?
6. A documentação de instalação e de deploy faz parte da entrega, com prazo definido?
7. Se a relação acabar, quantas horas de transição vocês se comprometem a dar, e a que valor?
8. Quais serviços pagos de terceiros o sistema vai usar, quanto custam por mês e quem paga?

Se o fornecedor hesitar em três ou mais dessas perguntas, isso não prova má-fé. Mostra apenas que a saída vai ser cara, e você precisa saber disso antes, não depois.

O barato que sai caro aqui é o seguinte: aceitar uma proposta mais baixa em que a infraestrutura “vem incluída” na conta do fornecedor. O desconto na entrada costuma ser menor que o custo de uma única migração forçada.

Se você já está preso, o caminho é o mesmo, só que na ordem inversa. Peça primeiro acesso de administrador ao repositório e ao banco. Depois leve as contas para o seu CNPJ. Por último, peça documentação. Faça isso enquanto a relação ainda está boa: o mesmo pedido, feito no meio de uma briga, custa bem mais caro.

Como a OCA monta um projeto com a porta de saída aberta

Esse é o tipo de projeto que a gente constrói, e a regra vale também para os nossos produtos. O Revo App, nossa plataforma de eventos com mais de 40 mil usuários, roda em React Native e Supabase. O Supabase é uma dependência consciente: economizou meses de backend e, por baixo, é PostgreSQL padrão. Se um dia for preciso trocar, os dados saem com um backup comum. O pagamento passa pelo Pagar.me, mas o gateway é uma integração do sistema, não a base dele. Trocar seria um projeto, não uma reescrita.

Nos projetos de clientes, aplicamos o mesmo critério: tecnologia de mercado, repositório e contas no nome do cliente e documentação de deploy como parte da entrega. A ideia é simples: o cliente deve continuar com a gente porque o trabalho é bom, não porque sair é caro. Você pode ver sistemas que seguem esse modelo no portfólio de projetos da OCA.

Próximo passo: faça o inventário de saída esta semana

Antes de falar com qualquer fornecedor, faça uma ação gratuita. Monte uma planilha com cinco linhas, uma para cada camada (código, dados, infraestrutura, stack e conhecimento), e quatro colunas: onde está, em nome de quem, se você tem acesso de administrador e quanto custaria sair, usando as faixas deste artigo. Em uma hora você descobre se está protegido ou se tem uma conta a pagar no futuro.

Se a planilha mostrar lacunas, ou se você está para contratar um sistema novo e quer montar o contrato certo desde o começo, a gente pode revisar com você.

Converse com a OCA sobre o seu sistema