A ligação chega numa terça. O site está no ar, o aplicativo funciona, o checkout processa pedidos — e ninguém na empresa sabe onde nada disso roda. O desenvolvedor parou de responder há três semanas. O domínio vence em quarenta dias, o certificado em dez, e a única pessoa que já digitou a senha do servidor não atende mais o telefone.
Este texto não é sobre processar ninguém. Ação judicial é assunto do seu advogado e não devolve o acesso ao painel de DNS. É um roteiro operacional das primeiras 48 horas, na ordem em que reduz risco — o que fazer nas primeiras duas horas, o que fazer no primeiro dia e o que só faz sentido depois que a poeira baixa. Se você só tiver tempo para o primeiro bloco, faça o primeiro bloco. Ele é o que impede o prejuízo de crescer.
Projeto órfão é o software que continua rodando em produção depois que a única pessoa capaz de operá-lo saiu — sem transferência de acessos, sem documentação e sem ninguém na empresa que consiga fazer o próximo deploy.
Primeiras 2 horas: inventário de titularidade, não de código
O instinto é abrir o código. É o instinto errado. Código parado não te machuca; conta expirada, sim. A primeira pergunta não é “o que esse sistema faz” — é “o que a empresa efetivamente controla hoje”.
Monte uma planilha com uma linha por ativo e três colunas: em nome de quem está, quem consegue entrar agora, quando vence. Os ativos são estes:
- Domínio. Onde está registrado e em nome de qual CPF ou CNPJ. Este é o item número um: perder o domínio é perder o negócio, e o prazo de renovação não espera a sua reorganização interna.
- DNS. Pode estar em provedor diferente do registrador. É o que aponta o domínio para o servidor.
- Hospedagem ou conta de nuvem. Inclui o cartão de crédito cadastrado. Fatura no cartão pessoal do desenvolvedor é uma bomba-relógio.
- Repositório de código. GitHub, GitLab, Bitbucket — e sob qual organização.
- Serviços de terceiros. Gateway de pagamento, e-mail transacional, SMS, storage, CDN, monitoramento, ferramenta de erro.
- Contas de loja de aplicativos, se houver app publicado.
- Banco de dados, se estiver fora do servidor principal.
Aqui existe uma distinção que confunde muita gente: titularidade não é o mesmo que acesso. O Registro.br é explícito sobre isso — um domínio pode pertencer a uma pessoa jurídica, mas a administração sempre é feita por uma pessoa física. Se o titular é o CNPJ da sua empresa e apenas o contato administrativo é o desenvolvedor, você tem um problema de procedimento, resolvível com documentação. Se o titular é o CPF dele, você tem um problema de negociação. São situações muito diferentes e vale descobrir em qual você está antes de tomar qualquer outra decisão.
Próximas 6 horas: revogar acesso, na ordem certa
Um ex-fornecedor com credencial ativa não é um risco teórico. É uma credencial válida sem dono responsável — exatamente a categoria que o Data Breach Investigations Report 2025 da Verizon aponta como vetor de acesso inicial em 22% das violações analisadas, o vetor mais frequente do relatório. Não é preciso supor má-fé: basta o notebook dele ser roubado, ou a senha reaproveitada dele aparecer num vazamento.
Mas revogar às cegas é como cortar fios coloridos no escuro. Chave de API cancelada sem aviso derruba pagamento, e-mail transacional e integração — em produção, no meio do expediente. Por isso o inventário vem antes. Com ele na mão, rotacione nesta ordem:
- Acesso administrativo primeiro. Painel do provedor de nuvem, painel do registrador, conta raiz. É o que permite destruir tudo o resto.
- Chaves SSH e deploy keys do servidor. Remova as chaves públicas que não são de ninguém identificado.
- Repositório. Remova o colaborador, revogue tokens pessoais e desative deploy keys órfãs.
- Senhas de banco de dados e painéis administrativos da aplicação.
- Chaves de serviços de terceiros, uma por vez, com alguém observando o comportamento em produção após cada troca.
- Webhooks e integrações apontando para endereços que você não reconhece.
Ative autenticação em dois fatores em tudo enquanto faz isso. E procure segredos versionados: arquivo .env commitado no repositório é comum em projeto de fornecedor pequeno, e significa que a credencial vaza junto com o código. Esse é o tipo de decisão estrutural que separa um projeto sustentável de um passivo, como descrevo em arquitetura segura para dados sensíveis.
Primeiro dia: descobrir se o código está inteiro
Só agora o código entra. A pergunta não é “esse código é bom” — é “esse código é suficiente para operar o sistema sem ele”. Quatro verificações respondem quase tudo:
- O repositório corresponde ao que está no ar? Compare o commit em produção com o último commit do repositório. Divergência significa que alguém subiu alteração direto no servidor, e a diferença pode conter regra de negócio que não existe em lugar nenhum além daquele arquivo.
- Você consegue subir o projeto do zero? Clone em uma máquina limpa e tente rodar. Se o build depende de um passo que só existia na cabeça de quem saiu, você descobre agora — não no dia em que precisar corrigir um bug urgente.
- Existe backup e ele restaura? Backup nunca restaurado é suposição, não garantia. Vale o mesmo princípio de backup e disaster recovery: teste a restauração antes de precisar dela.
- Como se faz um deploy? Se a resposta for “arrastando arquivo por FTP”, a primeira melhoria estrutural já está identificada. Uma esteira mínima é mais barata do que parece, como mostro em CI/CD sem drama.
Vale calibrar a expectativa sobre o custo de mexer em código herdado. A pesquisa The Developer Coefficient, da Stripe, já apontava em 2018 que pessoas desenvolvedoras gastam mais de 17 horas por semana com manutenção, depuração e correção de código ruim. O número é antigo e a amostra é global, mas a ordem de grandeza é o recado: manutenção de código que ninguém documentou consome a maior parte do orçamento de engenharia, não uma sobra dele. Planeje o próximo trimestre com isso em mente.
O que é um handover — e como cobrar um depois do fato
Um handover de projeto é a entrega formal de tudo que permite outra pessoa assumir o software sem consultar quem saiu. Não é um gesto de boa vontade no último dia: é entregável, e cabe em um documento de poucas páginas.
O conteúdo mínimo:
- Inventário de contas e credenciais, com titularidade e forma de recuperação.
- Endereço do repositório e do ambiente de produção.
- Procedimento de deploy, escrito passo a passo, incluindo rollback.
- Dependências externas, com custo, ciclo de cobrança e contato de suporte.
- Decisões de arquitetura que não são óbvias no código, e o motivo delas.
- O que costuma quebrar, e o que se faz quando quebra.
Mesmo com o fornecedor ausente, vale enviar esse pedido por escrito, por e-mail, listando item por item. Duas coisas acontecem: às vezes a pessoa responde — sumiço costuma ser conflito mal resolvido, não fuga —, e sempre fica registrado que você solicitou. Se o assunto virar disputa, esse registro é o que documenta a tentativa.
De quem é o código? A lei tem um padrão
No Brasil, a resposta padrão favorece quem contratou. A Lei 9.609/98, em seu artigo 4º, estabelece que os direitos sobre programa de computador desenvolvido durante a vigência de contrato de trabalho ou de prestação de serviços pertencem ao empregador ou contratante — salvo estipulação em contrário.
Essa ressalva é o ponto. O padrão legal só vale onde o contrato cala. Um contrato que atribui a propriedade ao fornecedor, ou que concede à empresa apenas licença de uso, inverte a situação — e contratos assim existem, principalmente em modelos de produto white label. Antes de afirmar que o código é seu, releia o que foi assinado.
E vale separar duas coisas que se confundem sob pressão: ser dono do código não te dá a senha. Direito autoral é uma disputa que se resolve em meses; acesso operacional é o que decide se o site fica no ar na semana que vem. Trate o acesso como emergência e a propriedade como processo.
Contratar quem assume: o que perguntar
Com o acesso recuperado e o código mapeado, vem a decisão de quem toca daqui pra frente. Duas recomendações práticas.
Primeiro: peça um diagnóstico curto e pago antes de qualquer contrato longo. Duas semanas de leitura do sistema, com entrega de um documento de riscos e prioridades, custa pouco e revela muito — inclusive sobre o fornecedor que você está avaliando.
Segundo: desconfie de quem propõe reescrever tudo na primeira conversa. Reescrita é a resposta confortável para quem não quer ler código alheio, e ela joga fora regra de negócio que só existe ali. Estabilize primeiro. Decida depois. Os critérios de avaliação completos estão em como escolher uma software house.
As cláusulas que impedem a segunda vez
O projeto órfão quase nunca é falha técnica. É cláusula que ninguém escreveu. Para o próximo contrato:
- Todas as contas em nome do CNPJ da empresa, com cartão corporativo. O fornecedor recebe acesso, não titularidade.
- Repositório na organização da empresa. O fornecedor entra como colaborador e sai como ex-colaborador, com um clique.
- Handover documentado como condição do pagamento final. É a única cláusula que garante que ele será escrito.
- Cessão de direitos explícita, para não depender da regra supletiva da lei.
- Prazo de resposta e procedimento de encerramento, definindo o que acontece nos 30 dias após o fim do contrato.
Nenhuma delas custa dinheiro. Custa lembrar de escrevê-las antes de começar — e é precisamente por isso que quase ninguém escreve.
Se você só tiver tempo para uma coisa hoje, faça esta: descubra em nome de quem está o domínio e quando ele vence. Todo o resto tem conserto mais lento.