Herdar código de outro dev: como avaliar, precificar e aceitar (ou recusar) um projeto que já vem pronto pela metade

A mensagem chega mais ou menos assim: "o dev que fazia nosso sistema sumiu, você consegue continuar de onde ele parou?". Você entrega bem, tem espaço na agenda, e o cliente parece decidido. Só tem um detalhe: você ainda não viu uma linha do código. Aceitar projeto herdado é uma das decisões mais arriscadas da vida de um dev freelancer, e quase ninguém fala sobre como fazer isso direito. A maioria aceita no escuro, descobre o buraco duas semanas depois e passa meses pagando com a própria margem por um problema que não criou.

Vou te falar como funciona do lado de quem recebe os leads: na OCA, uma parte relevante dos contatos que chegam todo dia é exatamente isso. Sistema pela metade, dev anterior fora do ar, cliente frustrado e desconfiado. Esses projetos podem ser ótimos ou podem ser armadilhas. A diferença está em como você avalia antes de dizer sim.

Por que projeto herdado é diferente de projeto novo

Em um projeto do zero, o risco principal é escopo. Em um projeto herdado, o risco principal é o que você não sabe que não sabe. O código pode não ter versionamento. O banco pode estar em uma conta que ninguém acessa. As credenciais de deploy podem estar no notebook do dev que sumiu. E o cliente, que não é técnico, jura que "está quase pronto, falta só um detalhe".

Esse "falta só um detalhe" é a frase mais cara do freelance brasileiro. Do ponto de vista do cliente, o sistema funciona 80%. Do ponto de vista técnico, os 20% que faltam podem exigir reescrever metade do que existe. Você só descobre olhando por dentro. Por isso a regra número um: nunca dê preço de continuação sem auditar o código antes.

A auditoria paga: seu seguro contra o buraco invisível

Auditar um sistema herdado dá trabalho de verdade: clonar o repositório (se existir), rodar o projeto localmente, mapear dependências, entender o banco, testar os fluxos principais. Isso leva de 4 a 16 horas dependendo do tamanho. E trabalho de verdade se cobra.

Ofereça a auditoria como um serviço fechado e separado. Faixas realistas em 2026: entre R$ 1.500 e R$ 5.000 para sistemas pequenos e médios, mais para plataformas grandes. O entregável é um relatório curto que responde quatro perguntas:

• O que existe e em que estado está (funciona, funciona com ressalvas, não funciona)?
• O que falta para chegar no que o cliente quer?
• Quais riscos estruturais existem (sem testes, sem versionamento, dependências abandonadas, dados sensíveis expostos)?
• Vale mais a pena continuar em cima do que existe ou reconstruir partes?

Isso resolve dois problemas de uma vez. Primeiro, você é pago para descobrir o tamanho do buraco em vez de descobrir de graça depois de assinar. Segundo, o relatório filtra cliente: quem recusa pagar uma auditoria de R$ 2.000 em um sistema que diz valer R$ 50.000 está te contando algo importante sobre como ele valoriza trabalho técnico. Isso não é teoria, é literalmente como a OCA trata todo pedido de resgate de sistema que chega, e o índice de projeto que azeda depois caiu muito quando a auditoria virou etapa obrigatória.

O checklist técnico antes de aceitar

Na auditoria, alguns pontos separam projeto viável de bomba-relógio:

Acesso e propriedade

• O cliente tem acesso ao repositório, ou o código está refém do dev anterior?
• Domínio, hospedagem, banco de dados e contas de serviço (Stripe, Pagar.me, Firebase, AWS) estão em nome do cliente?
• Existe contrato anterior definindo de quem é a propriedade intelectual?

Se o cliente não é dono de nada disso, o primeiro projeto não é continuar o sistema. É recuperar a posse dele. Deixe isso explícito e cobre como fase separada.

Saúde do código

• Tem README ou qualquer documentação? Roda localmente sem duas tardes de arqueologia?
• As dependências têm quantos anos? Versões abandonadas de framework são custo futuro garantido.
• Existe qualquer teste? Sem testes, cada mudança sua pode quebrar algo que você nem sabia que existia.
• Tem dado sensível no repositório (senha, chave de API, dado de usuário)? Isso é passivo de LGPD que passa a ser problema seu também.

Histórico do relacionamento

Pergunte por que o dev anterior saiu. A resposta importa menos que a forma como o cliente conta. Se ele descreve o dev anterior como incompetente, preguiçoso e caro, desconfie: pode ser verdade, ou pode ser o retrato de como ele vai falar de você em seis meses. Cliente que já queimou dois devs seguidos geralmente tem participação ativa no incêndio.

Como precificar continuação de sistema sem se enterrar

A conta é simples, mas quase ninguém faz: continuar código alheio custa mais por hora útil do que escrever do zero, porque uma parte do seu tempo vai para entender decisões que você não tomou. Na prática:

• Adicione margem de risco de 30% a 50% sobre a sua estimativa normal para as primeiras entregas em código herdado. Depois de dois ou três meses convivendo com a base, você calibra.
• Feche escopo pequeno primeiro. Em vez de orçar "terminar o sistema", orce o primeiro marco: fazer o deploy funcionar, estabilizar o fluxo de cadastro, corrigir os cinco bugs mais críticos. Entrega, mede, orça o próximo.
• Separe estabilização de evolução. Deixe claro no contrato que corrigir o que veio quebrado é um trabalho, e construir funcionalidade nova é outro. Quando tudo vira um pacote só, o cliente enxerga a estabilização como "você demorando para fazer o que o outro já tinha feito".
• Não dê garantia sobre o que você não escreveu. Sua garantia cobre o seu código. O legado que você ainda não tocou entra como está, e isso precisa estar escrito.

Quando recusar é a melhor decisão financeira

Alguns sinais indicam que o projeto herdado vai custar mais do que rende, em dinheiro ou em desgaste:

• Cliente se recusa a pagar auditoria e pressiona por preço fechado imediato.
• Ninguém tem acesso ao código e o dev anterior sumiu de vez. Sem código, não existe "continuar", existe reconstruir, e o cliente precisa aceitar esse enquadramento antes de qualquer proposta.
• O orçamento disponível é claramente incompatível com o estado do sistema. Se faltam R$ 40.000 de trabalho e o cliente tem R$ 5.000, nenhuma negociação honesta fecha essa conta.
• O cliente quer que você assuma prazo prometido pelo dev anterior. Prazo dos outros não é herança sua.

Recusar bem também constrói reputação. Um relatório de auditoria honesto dizendo "não vale continuar, e aqui está o porquê" transforma um não em indicação futura. Cliente lembra de quem foi direto quando todo mundo estava tentando empurrar contrato.

Projeto herdado pode ser o seu melhor nicho

Aqui vai a parte que pouca gente enxerga: resgatar sistema abandonado é um dos nichos mais bem pagos do freelance, exatamente porque a maioria dos devs foge dele. O cliente já foi queimado, já entendeu na pele que barato sai caro e chega disposto a pagar por senioridade. Se você tem estômago para ler código alheio e método para precificar risco, esse tipo de projeto paga melhor que projeto novo disputado com dez freelancers no orçamento.

Na OCA, esse perfil de demanda chega com frequência, junto com dezenas de outros leads que aparecem todo dia pelo Google e pelas IAs. É mais projeto do que o nosso time consegue atender, e é por isso que repassamos projetos avaliados e com escopo fechado para uma rede de devs parceiros seniores. Projeto herdado que passa pela nossa auditoria chega para o parceiro com o buraco já mapeado, o que elimina boa parte do risco descrito neste artigo. O que esperamos em troca: entrega consistente, comunicação clara com o cliente e honestidade quando algo sai do previsto. Se você já entrega bem, o seu problema não é técnico, é distribuição.

Entre para a rede de parceiros da OCA

E uma ação para esta semana, independente de qualquer rede: escreva o seu roteiro de auditoria de código herdado em um documento de uma página, com preço definido. Na próxima vez que chegar um "você consegue continuar de onde o outro parou?", você responde com processo em vez de responder com chute. Só isso já te coloca na frente de 90% dos devs que vão dar preço no escuro.