Uma empresa pagou R$ 15 mil por um sistema de controle de pedidos. O sistema funcionava. O freelancer entregou no prazo. Até aí, tudo bem. O problema apareceu seis meses depois, quando o dev parou de responder e a empresa precisou corrigir um bug crítico. O código estava na conta pessoal do GitHub do freelancer. O servidor estava no cartão de crédito do freelancer. O domínio foi registrado no e-mail pessoal do freelancer. A empresa tinha o sistema rodando, mas não tinha nada além disso.
A estrutura do problema é sempre a mesma: quem pagou não definiu, no dia 0, quem é o dono de cada ativo digital do projeto.
Por que a maioria das empresas perde o código, e o problema não é o freelancer ruim
A Lei nº 9.609/1998, conhecida como Lei do Software, é direta: sem contrato de cessão de direitos, os direitos patrimoniais do código pertencem ao desenvolvedor que o criou, não a quem pagou pelo projeto. O artigo 4º da lei trata especificamente de software desenvolvido por profissionais externos. Isso significa que um freelancer que trabalhou sem contrato formal pode, legalmente, impedir você de usar, copiar ou modificar o sistema que você financiou.
Isso não é má-fé. É a lei funcionando como foi escrita.
O segundo problema é operacional. Mesmo com um contrato bem redigido, se o repositório está na conta pessoal do dev, ele controla o acesso. Se o servidor está no cartão de crédito dele, ele controla a chave. Se o domínio foi registrado no e-mail dele, você depende da boa vontade de uma pessoa que talvez não atenda mais o telefone.
Não é sobre freelancer ruim ou bom. É sobre quem tem as credenciais quando o projeto termina.
O que garantir em contrato antes de o dev escrever a primeira linha
Antes de assinar qualquer coisa, você precisa de três cláusulas que a maioria dos contratos de freela não tem.
Cessão de propriedade intelectual (IP Assignment). A cláusula precisa dizer, com essas palavras, que o contratado cede ao contratante todos os direitos patrimoniais sobre o código produzido no escopo do projeto. Um exemplo que você pode levar para o advogado revisar:
O CONTRATADO cede ao CONTRATANTE, de forma total, exclusiva e irrevogável, todos os direitos patrimoniais sobre os programas de computador desenvolvidos no âmbito deste contrato, nos termos do art. 4º da Lei nº 9.609/1998, incluindo os direitos de reprodução, distribuição e modificação.
Sem isso, a lei presume que os direitos ficam com o dev. O INPI exige registro do contrato de cessão para que ele produza efeitos contra terceiros, então guarde o original assinado.
Titularidade dos ativos digitais. O contrato deve listar explicitamente: repositório de código, domínio, hospedagem, contas de serviços de terceiros (Google Cloud, AWS, Stripe, ou qualquer API crítica). Cada um desses itens precisa estar em nome da sua empresa, não do dev. Se o dev criou qualquer um deles em nome próprio, o contrato deve prever transferência formal antes do pagamento final.
Entrega do código-fonte com documentação. "Tá funcionando" não é entrega. O contrato precisa definir o que conta como entrega completa: código no repositório da empresa, variáveis de ambiente documentadas, instruções de deploy no README e lista de todas as dependências externas com suas respectivas credenciais de acesso.
Não precisa ser um contrato de 30 páginas. Precisa ter a cláusula de cessão de IP escrita com clareza, assinatura das duas partes e uma cópia que você encontra em 30 segundos se precisar acionar o advogado.
Repositório na conta certa: como configurar o GitHub como dono do projeto antes de começar
Esse é o passo que ninguém explica para quem não é técnico.
O GitHub tem dois tipos de conta: contas pessoais e Organizations. Uma Organization é uma conta no nome da empresa. Ela tem CNPJ, tem dono definido, e qualquer repositório criado dentro dela pertence à empresa, não ao dev que trabalhou no projeto.
Quando você cria um repositório na conta pessoal do freelancer, ele tem controle total. Ele pode arquivar, deletar ou revogar seu acesso sem aviso. Quando o repositório fica na Organization da sua empresa, você pode adicionar o dev como colaborador externo (Outside Collaborator) e revogar o acesso dele no dia que o projeto terminar, sem perder uma linha de código.
A própria documentação do GitHub recomenda explicitamente que empresas usem Organizations para repositórios corporativos, e orienta ter ao menos dois owners cadastrados para evitar bloqueio de acesso.
Como configurar antes de o dev começar:
- Acesse github.com e crie uma Organization em nome da sua empresa. Use o e-mail e o CNPJ da empresa, não seu e-mail pessoal.
- Crie o repositório do projeto dentro dessa Organization.
- Adicione o freelancer como Outside Collaborator com permissão de escrita (Write). Ele não precisa de mais que isso para trabalhar.
- Cadastre um segundo owner na Organization, que pode ser você mesmo com uma conta secundária ou outro responsável da empresa.
Quando o projeto terminar, você remove o freelancer. O código fica onde sempre esteve: na conta da sua empresa.
Checklist de cada entrega: o que pedir além do "tá funcionando"
Cada entrega parcial e a entrega final precisam seguir um protocolo mínimo. Isso não é burocracia por burocracia, é o que garante que você consiga dar manutenção quando o dev sumir.
Para cada entrega parcial:
- Pull request aberto no repositório da empresa, com descrição do que foi feito e por quê
- Lista de novas variáveis de ambiente adicionadas, com exemplos de valores (sem expor as credenciais reais)
- Confirmação de que o código está no repositório da empresa, não em branch local da máquina do dev
Para a entrega final:
- README atualizado com instruções de como rodar o projeto localmente e como fazer deploy em produção
- Arquivo com a lista completa de serviços externos usados: APIs, serviços de e-mail, gateway de pagamento, serviço de SMS, qualquer coisa que exige conta externa
- Para cada serviço externo: nome do serviço, URL do painel de acesso, conta em que está registrado (precisa ser conta da empresa)
- Credenciais de acesso ao banco de dados em nome da empresa
- Confirmação de que o servidor de produção está em conta da empresa, não do dev
Se o dev resistir a qualquer um desses pontos, não pague. Resistência na entrega de documentação não é capricho, é sinal de que ele sabe que tem mais poder do que deveria ter.
Acessos que jamais podem ficar só na mão do dev: servidor, domínio, banco de dados e e-mail
Esses quatro não são negociáveis. Se algum deles estiver no nome do dev quando o projeto terminar, você tem um problema.
Domínio. Para domínios .br, o acesso ao painel do Registro.br é vinculado ao CPF ou CNPJ do titular. O que isso significa na prática: se o domínio foi registrado com o CNPJ da sua empresa, você pode recuperar o acesso apresentando documentação, mesmo que o dev tenha criado o login e a senha originalmente. Se foi registrado no CPF do dev, o domínio não é seu.
Antes de o projeto começar: o domínio precisa estar registrado no CNPJ da empresa. Se já está em nome do dev, o Registro.br tem um procedimento formal de Transferência de Titularidade que não exige a senha do titular anterior, só documentos com firma reconhecida ou assinatura digital enviada para doc@registro.br.
Servidor e hospedagem. O risco aqui é o mesmo do repositório: se o servidor está na conta pessoal do dev, ele controla a chave. Para PMEs, o padrão ainda é host compartilhado ou VPS. Em qualquer caso, a conta do serviço de hospedagem precisa estar no nome da empresa, com o cartão de crédito da empresa.
Banco de dados. O usuário administrador do banco de dados precisa ter credenciais que você conhece. Peça ao dev que documente o usuário root, a senha e o host. Se o banco está em um serviço gerenciado (como AWS RDS ou PlanetScale), a conta precisa ser da empresa.
Contas de e-mail transacional. Se o sistema envia e-mail (confirmação de pedido, recuperação de senha, qualquer coisa), ele usa um serviço como SendGrid, Amazon SES ou Mailgun. Essas contas têm limites de envio, histórico de reputação e, muitas vezes, domínio verificado. Se estiverem no nome do dev, você perde o histórico e a reputação quando ele for embora.
Protocolo de emergência: o que fazer passo a passo quando o freelancer some com o repositório
Em junho de 2026, 73 repositórios oficiais da Microsoft no GitHub foram derrubados por ataque em questão de minutos, travando deploys de clientes que dependiam deles. Até a Microsoft ficou vulnerável por conta de repositórios fora do seu controle direto. Para uma PME, o cenário equivalente é o dev que some.
Se o freelancer sumiu e você não tem acesso ao código, siga essa ordem:
Passo 1: recupere o que está no servidor de produção. O sistema está rodando em algum servidor. Esse servidor tem um IP. Se você tem acesso ao painel do hosting (mesmo que não saiba o que fazer com ele), um técnico consegue conectar via SSH ou FTP e extrair o código de produção. Esse código não é o histórico completo do desenvolvimento, mas é o que está rodando agora. É melhor que nada.
Passo 2: entre em contato com o suporte do serviço de hospedagem. Apresente documentação comprovando que é o responsável pela empresa e solicite transferência de titularidade da conta. A maioria dos serviços tem esse procedimento. Hospedagens como Locaweb e HostGator Brasil aceitam documentação da empresa para fazer essa transferência.
Passo 3: recupere o domínio pelo Registro.br. Se o domínio .br está em nome da sua empresa (CNPJ), você pode recuperar o acesso ao painel do Registro.br apresentando documento da empresa, mesmo sem a senha original. Acesse registro.br e use o formulário de recuperação de acesso. Se o domínio está em nome do dev (CPF dele), você vai precisar do procedimento de Transferência de Titularidade via documentação. O Registro.br aceita solicitação enviada para doc@registro.br com documentos de ambas as partes com firma reconhecida.
Passo 4: use o Whois para comprovar titularidade. O Whois é um banco de dados público que mostra quem é o titular registrado de um domínio. Em disputas com o dev sobre quem é o dono do domínio, o Whois é evidência documental. Acesse registro.br/cgi-bin/whois para consultar.
Passo 5: documente tudo antes de partir para via jurídica. Registre todos os contatos tentados com o dev, todas as respostas (ou ausência de resposta), todos os valores pagos. Se houver contrato com cláusula de cessão de propriedade intelectual assinado, você tem base legal para exigir a entrega do código. Sem contrato, a Lei do Software vai ser um obstáculo, não um aliado.
Se o dev manteve o repositório na conta pessoal dele e negou acesso, a recuperação completa do histórico de desenvolvimento pode ser impossível sem cooperação. Essa é a consequência direta de não ter configurado a Organization no dia 0.
Três verificações antes de assinar qualquer contrato de freela
Se você vai contratar um dev freelancer, três coisas precisam estar resolvidas antes da primeira linha de código:
- A Organization no GitHub precisa estar criada em nome da empresa.
- O contrato precisa ter cessão de propriedade intelectual assinada.
- O domínio, o hosting e qualquer serviço externo crítico precisam estar em nome da empresa.
Se você já tem um sistema rodando e não sabe responder de onde está o repositório, quem é o titular do domínio e se você tem acesso ao servidor sem precisar ligar para o dev, você já está no cenário que esse artigo descreveu.
Para fazer essa verificação, você não precisa entender o que é um pull request. Precisa saber quem tem as senhas.
A Coffe&Code Labs faz um diagnóstico gratuito de acesso para mapear o que a empresa controla de fato. Leva menos tempo do que recuperar um domínio pelo Registro.br depois que o freelancer sumiu. Antes de assinar o próximo contrato, veja também quanto custa manter um sistema após a entrega e fale com a gente.