Assumir projeto de outro dev no freelance: como orçar código herdado sem levar prejuízo (o diagnóstico pago e as faixas de preço de 2026)

A mensagem chega no WhatsApp numa terça à noite: “O dev que estava fazendo meu app sumiu. Falta só uns 20% para terminar. Você consegue assumir?” Junto vem um link de TestFlight que não abre, um print do Trello com metade dos cards em “Done” e a frase que todo freelancer conhece: “já está quase pronto”.

Você entrega bem, a stack é a sua, o cliente está com pressa e quer pagar. Parece o projeto mais fácil do mês. Só que assumir projeto de outro dev é um dos trabalhos que mais dão prejuízo a freelancer experiente, justamente porque parece fácil. Você não está orçando uma funcionalidade. Está orçando o desconhecido, e de quebra herda a frustração de um cliente que já pagou uma vez e nunca viu o produto rodar.

Este artigo mostra como orçar código herdado sem perder dinheiro: o diagnóstico pago, a conta com margem e os cuidados que te protegem.

Por que o “falta só 20%” quase nunca é 20%

Vou te falar como funciona do lado de quem recebe os leads: na OCA, pedido para “assumir projeto parado” chega toda semana. Depois de abrir alguns desses repositórios, a gente parou de acreditar no percentual de conclusão que o cliente informa. Não é que o cliente minta. Ele mede o progresso pelas telas que viu, e tela pronta não é produto pronto.

Os 20% que faltam costumam ser justamente a parte difícil: pagamento, autenticação, regras de negócio cheias de exceção, deploy em produção, publicação nas lojas. As telas são a parte rápida. O dev anterior provavelmente fez primeiro o que aparecia e travou quando chegou no que dá trabalho.

E tem um segundo problema: você não herda só o código. Herda as decisões que ninguém documentou, as dependências que ninguém atualizou e a expectativa de um cliente que já investiu e quer resultado rápido. A conta é simples: se você orçar código herdado como se fosse projeto novo, vai trabalhar de graça na parte que ninguém vê.

Diagnóstico pago: o que fazer antes de dar qualquer preço

A regra que a OCA segue é direta: não tem orçamento de projeto herdado sem diagnóstico, e diagnóstico é trabalho pago. Você vai passar de 2 a 5 dias lendo código de outra pessoa. Isso vale dinheiro para o cliente mesmo que vocês não sigam juntos, porque ele sai com um raio-x do que comprou.

Passo 1: acessos antes de qualquer conversa sobre preço

Peça a lista completa e confirme que o cliente é dono de cada item:

• Repositório (GitHub, GitLab, Bitbucket) com o histórico de commits, e não um zip
• Conta de cloud ou de backend (AWS, Vercel, Supabase, Firebase)
• Banco de dados de produção ou, no mínimo, um dump recente
• Contas de desenvolvedor na Apple e no Google Play em nome da empresa do cliente
• Domínio, DNS e serviços de terceiros (gateway de pagamento, e-mail transacional, APIs)

Se o repositório está na conta pessoal do dev que sumiu e o cliente não tem acesso, pare por aí. O primeiro trabalho não é técnico: é o cliente recuperar o que é dele. Mexer em código que ainda está em disputa é se colocar no meio de um problema que não é seu.

Passo 2: o roteiro do diagnóstico

1. Roda localmente? Clone, instale e tente subir. Se só para rodar levar mais de meio dia, isso já entra no orçamento.
2. Build e deploy. O app gera build para iOS e Android? O sistema web tem pipeline, ou o deploy era feito à mão a partir da máquina do dev?
3. Dependências. Rode npm outdated e confira as versões do Expo SDK, do React Native e do Next.js. Um app parado há um ano num SDK antigo pode exigir semanas só de atualização para voltar a ser publicado na loja.
4. Segredos e segurança. Chave de API no código, senha de banco commitada, regras de acesso abertas no banco.
5. Histórico do Git. Data do último commit, frequência, mensagens. Vários “fix” seguidos no mesmo arquivo mostram onde o projeto sangra.
6. Funciona ou só aparece? Teste cada fluxo que o cliente considera pronto. Marque o que funciona de ponta a ponta e o que é só tela.

Passo 3: o entregável e quanto cobrar

O diagnóstico vira um relatório curto, com um semáforo por módulo: verde (aproveita como está), amarelo (aproveita com ajustes) e vermelho (reescreve). No fim, uma estimativa por fase e a lista de riscos.

Em 2026, para um app ou sistema de porte pequeno a médio, um diagnóstico sério leva de 16 a 40 horas. Com a hora entre R$ 120 e R$ 200, isso dá de R$ 2.000 a R$ 8.000. O que mexe no número: tamanho do código, quantidade de integrações, se o app já está nas lojas e se existe banco de produção com dados reais. Para diminuir a resistência do cliente, ofereça abater o valor do diagnóstico do projeto caso ele feche com você em até 30 dias.

Como orçar código herdado com margem para o desconhecido

Com o diagnóstico na mão, você para de chutar. Mesmo assim, código herdado tem riscos que só aparecem quando você começa a mexer. A margem precisa estar no orçamento, e de forma explícita.

O modelo que mais protege é dividir o trabalho em duas fases. A fase de estabilização cobre fazer o projeto rodar, atualizar as dependências críticas, montar o deploy e corrigir o que impede o uso. Ela é cobrada por hora, com teto combinado e relatório semanal. A fase de evolução cobre o que o cliente chama de “os 20% que faltam”, com escopo fechado em cima de uma base que agora você conhece.

Um exemplo com números

Um app React Native parado há 10 meses. O cliente diz que falta só login social e pagamento. O diagnóstico (24 horas, R$ 3.600 a R$ 150 a hora) mostra que o Expo SDK está três versões atrás, o build de iOS está quebrado, não há nenhum teste e o “pagamento pronto” era só a tela de checkout, sem integração com o gateway.

• Estabilização: 40 a 60 horas, entre R$ 6.000 e R$ 9.000, em 2 a 3 semanas
• Evolução: login social e integração de pagamento com webhook, estimados em 80 horas, mais 30% de margem: R$ 15.600, em 3 a 4 semanas

Somando o diagnóstico, o total fica entre R$ 25 mil e R$ 28 mil, contra os “uns R$ 8 mil para terminar” que o cliente tinha na cabeça. É por isso que o diagnóstico vem antes: ele justifica o número com evidência, e não com a sua palavra contra a do dev anterior.

As armadilhas de assumir projeto de outro dev

Dar garantia sobre código que você não escreveu

Três semanas depois da entrega, quebra uma tela que você nunca tocou. Para o cliente, agora o app é seu. Deixe no contrato que a garantia cobre apenas o que você escreveu ou alterou, e que defeitos em código herdado fora do escopo são orçados à parte.

Não perguntar por que o dev anterior saiu

Às vezes o dev sumiu mesmo. Às vezes o cliente mudava o escopo toda semana, atrasava pagamento ou não respondia. Pergunte direto, ouça com atenção e, se der, converse com o dev anterior. Se você é o terceiro a assumir o mesmo projeto, o problema provavelmente não está no código.

Falar mal do código na frente do cliente

Dá vontade, mas não faça. Você não sabe com que prazo, orçamento e briefing aquele código foi escrito. No relatório, descreva o estado com fatos (“o build de iOS falha na versão X”), sem adjetivos. Isso passa mais confiança do que qualquer crítica e te protege no dia em que alguém assumir o seu código.

Aceitar um orçamento ancorado no que o cliente já pagou

“Já gastei R$ 60 mil, não vou pagar mais R$ 30 mil.” O que já foi pago não muda o trabalho que falta. A sua resposta é o relatório do diagnóstico: ele mostra o que existe, o que funciona e o que ainda precisa ser feito.

Começar reescrevendo tudo

A vontade de jogar tudo fora e fazer do seu jeito é grande. Reescrever só se justifica quando o diagnóstico mostra que estabilizar sai mais caro do que refazer. E essa decisão precisa estar no papel, aprovada pelo cliente, com o custo de cada opção lado a lado.

Do lado de quem recebe os leads: a rede de parceiros da OCA

A OCA aparece no Google e nas IAs quando alguém pesquisa desenvolvimento de software no Brasil. Isso não é teoria, é literalmente como a OCA cresceu. Por isso chegam dezenas de leads por dia, mais do que o time dá conta de atender, e parte deles é exatamente esse cenário: projeto parado, dev que sumiu, cliente com pressa.

Foi por isso que a OCA começou a montar uma rede de parceiros: devs seniores e pequenos times que recebem projetos já qualificados e com escopo fechado. Nos casos de código herdado, o objetivo é que o parceiro receba o projeto com os acessos confirmados e com o cliente já sabendo que existe uma fase de diagnóstico.

O que a OCA espera de um parceiro:

• Experiência real em produção na stack do projeto (React, React Native, Node e Next.js aparecem muito)
• Capacidade de ler código alheio sem drama e de escrever um diagnóstico que um cliente não técnico entenda
• Comunicação semanal, sem que o cliente precise cobrar
• Contrato e cobrança organizados, com CNPJ

O que o parceiro ganha: projetos que já passaram por um filtro, escopo discutido antes de chegar até você e um cliente que veio pela reputação construída com produtos que a OCA opera em produção, como os do portfólio de projetos da OCA. Ninguém promete volume, e ninguém entra automaticamente. O primeiro passo é uma conversa para entender se o seu trabalho combina com o tipo de projeto que chega.

O próximo passo

Se você quer receber parte dos projetos que a OCA não consegue absorver, comece pela conversa:

Entre para a rede de parceiros da OCA

E, entrando ou não, faça uma coisa esta semana: monte o seu modelo de relatório de diagnóstico. Uma página com a lista de acessos, o roteiro de seis itens deste artigo, o semáforo por módulo e um espaço para a estimativa por fase. Na próxima vez que chegar um “falta só 20%”, você responde no mesmo dia com uma proposta de diagnóstico pago, em vez de um chute que vai sair caro.