Dependência de fornecedor de software: como não virar refém da software house (o checklist de código, acessos e contrato para exigir antes de assinar)

Você decide trocar de fornecedor de software. Talvez o atendimento piorou, talvez o preço da manutenção subiu sem explicação, talvez você só queira colocar um segundo time para acelerar. Aí começam as surpresas. O repositório do código está na conta pessoal de um dev que nem trabalha mais lá. O domínio foi registrado no CNPJ da agência. A conta da nuvem é paga no cartão do fornecedor, e você só recebe a fatura repassada. O app na App Store aparece publicado com o nome de outra empresa.

Ninguém roubou nada. Mas, na prática, o sistema que você pagou para construir não está nas suas mãos. Sair vira uma negociação, e quem negocia sem as chaves negocia em desvantagem. Quem já passou por um projeto travado sabe do que estou falando.

A boa notícia: quase toda essa dependência se evita com decisões simples no começo do projeto, que custam pouco ou nada. Este artigo é o checklist para isso.

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

Na maioria dos casos que eu herdo, não houve má-fé. Houve pressa. No início do projeto, o fornecedor cria as contas no próprio nome porque é mais rápido. Ele já tem o cartão cadastrado na AWS, já tem conta de desenvolvedor na Apple, já sabe mexer no Registro.br. O cliente agradece, porque quer ver o sistema funcionando, não configurar acesso.

Dois anos depois, essa conveniência virou estrutura. E tem outro fator: a dependência não aparece em lugar nenhum enquanto a relação vai bem. Ela só fica visível no dia em que você precisa sair. Por isso ninguém pergunta antes.

Vale separar o problema em quatro tipos, porque cada um tem um custo de saída diferente.

Os 4 tipos de dependência de fornecedor (e quanto custa sair de cada um)

1. Dependência de acesso

Repositório de código, domínio, conta de nuvem, contas nas lojas de aplicativo, painel do gateway de pagamento, e-mail transacional. Se estão no nome do fornecedor, você depende da boa vontade dele para qualquer mudança. Com cooperação, transferir tudo leva de alguns dias a duas semanas. Sem cooperação, pode levar meses. Em alguns casos não tem volta: um app que precisa ser republicado em outra conta perde as avaliações e obriga o usuário a baixar de novo.

2. Dependência de propriedade

O contrato não diz claramente que o código é seu. A Lei do Software (Lei 9.609/98) favorece o contratante em boa parte dos casos, mas "em boa parte dos casos" não é o que você quer ouvir de um advogado no meio de uma disputa. Uma cláusula explícita de cessão de direitos patrimoniais resolve isso no papel, sem custo.

3. Dependência de tecnologia

O sistema foi construído em um framework próprio do fornecedor, em uma plataforma no-code com licença no CNPJ dele, ou numa linguagem que pouca gente no mercado domina. Aqui o custo de saída é o mais alto, porque muitas vezes significa reescrever. Em sistemas de porte médio, uma reescrita costuma ficar entre R$ 80 mil e R$ 300 mil, com prazo de 3 a 8 meses. O que move esse número é o volume de regras de negócio e de integrações.

4. Dependência de conhecimento

Não existe documentação. Só uma pessoa sabe fazer o deploy, onde ficam as variáveis de ambiente e por que aquela rotina roda às 3 da manhã. Um time novo consegue entender o sistema mesmo assim, mas paga em horas de investigação. Na minha experiência, um onboarding sem documentação custa de 2 a 4 vezes mais do que com um README decente: algo entre R$ 15 mil e R$ 40 mil, em vez de R$ 5 mil a R$ 10 mil, para um sistema médio.

Nem toda dependência de fornecedor é ruim

Antes do checklist, uma honestidade necessária. Você sempre vai depender de alguém. Usar AWS, Supabase ou Pagar.me é depender de fornecedor. Contratar um SaaS pronto também é, e muitas vezes é a escolha certa, porque o custo de construir e manter algo sob medida não se paga.

A pergunta não é "como não depender de ninguém". É "se eu precisar trocar, quanto custa e quanto tempo leva?". Não existe resposta única, mas existe conta certa. Dependência aceitável é aquela em que você conhece o preço da saída e consegue pagar. Dependência perigosa é aquela que você só descobre quando precisa sair.

O mesmo vale para o acesso administrativo. O fornecedor precisa ter, para trabalhar. O que importa é quem é o dono da conta e quem pode tirar o acesso de quem.

Checklist: o que exigir antes de assinar com uma software house

Antes de assinar qualquer contrato, pergunta isso:

1. O repositório vai ficar em uma organização da minha empresa? GitHub, GitLab ou Bitbucket, criado com um e-mail corporativo seu. O fornecedor entra como membro. A resposta aceitável é sim, sem discussão.
2. O domínio está registrado no meu CNPJ? No Registro.br, o titular é quem decide. O fornecedor pode ser contato técnico, nunca titular.
3. A conta de nuvem é minha? AWS, Google Cloud, Vercel, Supabase: conta criada pela empresa, cartão da empresa, fornecedor com usuário próprio e permissões limitadas. Bônus: você passa a ver o custo real de infraestrutura, sem repasse com margem.
4. As contas das lojas de aplicativo estão no nome da empresa? Apple Developer Program (US$ 99 por ano) e Google Play Console (US$ 25, pagamento único), ambas cadastradas como organização, com CNPJ e o número D-U-N-S que a Apple exige. É o item que mais dói quando é esquecido.
5. O contrato tem cessão total dos direitos patrimoniais do código? Escrito assim, com essas palavras. Se o fornecedor reaproveita bibliotecas próprias entre clientes, o contrato precisa garantir a você uma licença perpétua e irrevogável de uso delas.
6. A stack é de mercado? Pergunte: "se vocês sumirem amanhã, quantos devs no Brasil conseguem dar manutenção nisso?". React, Node.js, Next.js, PostgreSQL, React Native: milhares. Framework interno: só eles.
7. Documentação é entregável com prazo? No mínimo: como rodar o projeto localmente, como fazer deploy, lista de serviços externos e onde ficam as credenciais. Precisa estar no cronograma, não em "quando sobrar tempo".
8. Existe cláusula de transição? Se o contrato terminar, o fornecedor se compromete com um período de passagem, normalmente de 15 a 30 dias, para transferir acessos e responder dúvidas do novo time, com valor de hora já definido.

Repare que nenhum desses itens deixa o projeto mais caro de forma relevante. O que eles mudam é o seu poder de decisão. Um fornecedor sério responde "sim" para os oito em uma única reunião. Se alguma resposta vier com rodeio, esse é o dado mais importante da negociação.

Já está preso? Como recuperar o controle sem brigar com o fornecedor

Se você leu até aqui e percebeu que metade dos itens não está no seu nome, calma. Na maioria das vezes dá para corrigir sem trocar de fornecedor e sem conflito.

1. Faça o inventário. Uma planilha com cada serviço (código, domínio, nuvem, lojas, gateway, e-mail, analytics), quem é o dono da conta hoje e quem paga.
2. Peça a transferência como rotina de governança, não como desconfiança. "Nossa contabilidade pediu que os ativos fiquem no CNPJ da empresa" funciona melhor que "quero garantir que vocês não me prendam".
3. Comece pelo que é irreversível. Domínio e contas das lojas primeiro. Código pode ser copiado a qualquer momento, mas um app removido de uma conta que não é sua não volta com o histórico.
4. Inclua a documentação mínima no próximo ciclo de manutenção. Se você já paga manutenção mensal, essas horas cabem no contrato atual.
5. Formalize com um aditivo. Cessão de direitos e cláusula de transição. Para um contrato em andamento, um aditivo de uma página resolve.

Se o fornecedor resistir a qualquer um desses passos, você não tem um problema técnico. Tem um problema comercial, e é melhor descobrir agora do que no dia da rescisão.

Como a OCA trata código, acessos e documentação

Boa parte do meu trabalho na OCA é assumir sistemas que outros times deixaram para trás. Já vi domínio que levou semanas para ser recuperado e app que precisou ser republicado do zero porque a conta da loja era do fornecedor anterior. Por isso, nos nossos projetos, o padrão é o contrário: repositório na organização do cliente, nuvem e lojas no CNPJ do cliente, e a gente entrando como convidado.

A mesma lógica vale para o que é nosso. O Revo App, nossa plataforma de eventos com mais de 40 mil usuários, roda em stack de mercado (React Native, Supabase, Pagar.me) justamente para que qualquer dev sênior consiga entrar no projeto. O sistema de gestão para imobiliárias, que está em produção, segue o mesmo princípio. Você pode ver esses e outros casos na página de projetos da OCA.

Esse é o tipo de projeto que a gente constrói: sistema sob medida que continua sendo do cliente, inclusive se um dia ele decidir seguir com outro time.

Tem uma ação gratuita que você pode fazer esta semana. Abra uma planilha, liste os oito itens do checklist e marque, para cada um, em nome de quem está hoje. Em uma hora você sabe qual é o seu custo real de saída.

Se quiser uma segunda opinião sobre o resultado, ou se está prestes a contratar um sistema e quer começar do jeito certo, fala com a gente.

Converse com a OCA sobre o seu sistema