Quando uma empresa contrata desenvolvimento de software, a conversa quase sempre gira em torno de prazo, funcionalidades e preço. Tem uma pergunta que pouca gente faz e que pode custar caro depois: quem fica com o código fonte?
A resposta decide se, daqui a dois anos, a empresa vai poder trocar de fornecedor, contratar outro time para evoluir o sistema ou simplesmente continuar operando se a relação acabar mal. E a hora de fazer essa pergunta é antes da assinatura, quando a empresa ainda tem poder de negociação.
O problema do lock-in
Lock-in é quando você contrata uma empresa para construir software e, no fim, não consegue levar o código para outro lugar. Não pode contratar outro desenvolvedor para fazer melhoria. Não pode trocar de fornecedor sem recomeçar do zero. Fica refém.
Isso acontece por quatro caminhos, e eles costumam aparecer juntos:
- Tecnologia proprietária: o sistema foi feito numa plataforma ou framework que só a software house sabe manter.
- Contrato omisso: o contrato não prevê entrega do código nem cessão de direitos.
- Falta de documentação: o código até é entregue, mas ninguém além de quem escreveu consegue entender.
- Infraestrutura na conta do fornecedor: servidor, banco de dados e domínio estão em nome da software house.
Nenhum desses caminhos aparece na proposta comercial. Eles surgem quando a empresa tenta sair, e aí a negociação já mudou de lado.
O que a lei diz sobre o código fonte
A Lei 9.609/1998, conhecida como Lei do Software, trata do tema no artigo 4º. Salvo estipulação em contrário, os direitos sobre o programa desenvolvido por contratado de serviço, dentro de um contrato destinado a isso, pertencem ao contratante.
O ponto frágil está justamente no "salvo estipulação em contrário". O contrato pode dizer outra coisa, e há modelos de contrato que licenciam o uso do sistema sem ceder o código. Na prática, a empresa só está protegida quando a cessão está escrita.
Mesmo com o direito garantido, ter o direito sem ter o arquivo resolve pouco. O código precisa estar num lugar a que a empresa tenha acesso, com histórico e com instruções para rodar. Direito no papel e código na mão são coisas diferentes, e as duas precisam existir.
As 5 perguntas que protegem você
1. O código fonte será entregue, e quando?
A resposta precisa ser sim, sem condição. Se aparecer algo como "entregamos após 12 meses de contrato de manutenção", é lock-in disfarçado. O melhor cenário é o repositório criado na conta da sua empresa desde o primeiro dia, com a software house trabalhando lá dentro.
2. A documentação técnica está incluída?
Código sem documentação é quase tão ruim quanto código sem entrega. Se outro desenvolvedor não consegue ler, instalar e entender, a dependência continua. A documentação precisa ser item de entrega no contrato, com o mínimo definido: como rodar o sistema, como publicar uma nova versão, como o banco está organizado e onde ficam as integrações.
3. Qual tecnologia vocês usam?
Tecnologias de mercado (React, Node, Python, PostgreSQL, entre outras) significam que qualquer desenvolvedor competente consegue dar manutenção. Framework proprietário ou exótico significa que o universo de quem pode assumir o sistema fica pequeno, e caro.
4. Onde fica hospedado?
Se o sistema roda na infraestrutura do fornecedor e não pode ser migrado, é outra forma de lock-in. O ideal é que a hospedagem fique na conta da sua empresa (AWS, Google Cloud, Azure ou outra) desde o início, com o fornecedor como usuário convidado. O mesmo vale para o domínio, que deve estar registrado em nome da empresa.
5. O que acontece se a software house fechar?
Se a resposta for "aí complica", o risco é real. A resposta certa é algo como: você tem o código, a documentação e o acesso à infraestrutura, então outro time assume e o sistema continua operando.
Resposta boa e sinal de alerta
| Pergunta | Resposta que protege | Sinal de alerta |
|---|---|---|
| Entrega do código | Repositório na conta da empresa desde o início | Entrega só no fim, ou após período de manutenção |
| Direitos | Cessão dos direitos patrimoniais escrita no contrato | Licença de uso do sistema, sem cessão |
| Documentação | Item de entrega com escopo mínimo definido | "O código é autoexplicativo" |
| Tecnologia | Linguagens e bancos de mercado | Plataforma própria do fornecedor |
| Infraestrutura | Conta de nuvem e domínio em nome da empresa | Servidor do fornecedor, sem plano de migração |
| Saída | Plano de transição previsto em contrato | Nenhuma cláusula sobre fim de contrato |
O checklist de acessos que a empresa precisa ter
Além do código, alguns acessos precisam estar em nome da empresa ou, no mínimo, com credencial de administrador guardada por alguém de dentro:
- Repositório de código, com histórico completo de alterações.
- Conta de nuvem onde o sistema roda, com a empresa como dona.
- Banco de dados e rotina de backup.
- Domínio e configuração de DNS.
- Chaves de serviços externos (e-mail, pagamento, mapas, IA).
- Contas nas lojas de aplicativo, quando houver app.
Vale fazer esse levantamento também em sistemas que já estão no ar. É comum descobrir que a conta de nuvem está no cartão de um ex-funcionário ou no e-mail pessoal de quem desenvolveu.
Quando o sistema já existe e o código não está com você
Muitas empresas só pensam nisso depois, com o sistema rodando há anos e a relação com o fornecedor já desgastada. Ainda dá para arrumar, e a ordem importa.
Primeiro, leia o contrato atual procurando três coisas: cláusula de cessão de direitos, obrigação de entrega do código e regras para o fim do contrato. É isso que define o tamanho da conversa.
Depois, faça o inventário do que a empresa já tem: quais contas estão em nome dela, quais estão com o fornecedor, quem tem senha de administrador de cada coisa. Esse levantamento, sozinho, costuma revelar a maior parte do risco.
Com o inventário na mão, a negociação fica objetiva. Em vez de "queremos o código", o pedido vira uma lista: repositório transferido, conta de nuvem migrada, domínio no nome da empresa, documentação mínima entregue até uma data. Fornecedor sério atende sem drama, porque sabe que isso é padrão de mercado.
Por fim, peça uma revisão técnica independente do que foi entregue. Ela confirma se o código recebido é mesmo o que está em produção e se outro time consegue assumir.
Erros comuns na contratação
O primeiro é comparar propostas só pelo preço e pelo prazo. Duas propostas de valor parecido podem esconder condições opostas de propriedade do código. Isso pesa no custo total tanto quanto a hora de desenvolvimento, e é o mesmo raciocínio que usamos para abrir quanto custa implantar IA: o preço da proposta é só uma parte da conta.
O segundo é aceitar que o fornecedor crie as contas "para agilizar". Criar a conta de nuvem ou o repositório leva minutos. Transferir depois pode levar semanas, se o fornecedor colaborar.
O terceiro é deixar a documentação para o fim. Documento escrito às pressas na última semana de projeto costuma ser incompleto. Documentação feita junto com o código acompanha o sistema de verdade.
O quarto é não testar a saída. Uma forma simples de conferir se o código é mesmo da empresa: pedir que alguém de fora, ou de outro time, tente rodar o sistema a partir do repositório e da documentação. Se não conseguir, a dependência ainda existe.
Como a Devvo trata o código
Na Devvo, a postura é clara: o código é do cliente, a documentação é do cliente e a infraestrutura fica na conta do cliente. Se o cliente quiser levar o sistema para outro time amanhã, leva. Parceiro bom é o que deixa você livre para ir embora.
Essa é uma das perguntas que mais pesam na hora de escolher quem vai construir o sistema. Outras aparecem no nosso guia sobre como escolher uma software house, que cobre time, método e forma de acompanhamento. E, se a dúvida ainda é entre comprar um sistema pronto ou construir, vale comparar ERP ou software sob medida, porque a questão da dependência aparece nos dois caminhos, com formas diferentes.
Quem pergunta sobre o código fonte antes de assinar negocia com calma. Quem descobre o problema na hora de sair negocia com pressa, e quase sempre paga mais caro.
