Subcontratar outro dev no freelance: quando dividir o projeto compensa e como fazer sem quebrar

Chega uma hora que todo freelancer que entrega bem vive o mesmo problema: aparece um projeto maior do que a sua capacidade. Ou dois projetos bons ao mesmo tempo. Você faz a conta de horas e não fecha. As opções na mesa são três: recusar, atrasar tudo, ou chamar outro dev para dividir. A terceira parece óbvia, mas é onde muito freelancer quebra. Não por falta de código, por falta de conta. Subcontratar sem margem, sem contrato e sem processo transforma um projeto lucrativo em prejuízo com juros.

Eu já estive dos dois lados dessa mesa. Hoje, na OCA, repassar projeto para outros devs é literalmente parte do modelo de negócio. Então vou te falar como funciona do lado de quem repassa, e o que eu queria ter sabido na primeira vez que subcontratei alguém.

Quando subcontratar compensa (e quando é armadilha)

A conta é simples. Subcontratar só faz sentido quando pelo menos uma dessas condições é verdadeira:

• O projeto paga a margem. Se você fechou o projeto por R$ 40 mil e o dev que vai executar 60% dele cobra R$ 30 mil, não existe negócio. Regra prática: o valor repassado não deveria passar de 60% a 70% do que aquele bloco de trabalho representa no contrato.
• Você agrega algo além de repassar. Gestão do cliente, arquitetura, revisão de código, garantia de entrega. Se você só encaminha mensagem do cliente para o dev, você é um intermediário caro e o cliente vai perceber.
• Recusar custa mais do que dividir. Um cliente bom que você recusa hoje raramente volta. Às vezes vale dividir um projeto com margem apertada para manter o relacionamento e a recorrência.

E quando é armadilha: subcontratar para salvar um projeto que já está atrasado. Colocar gente nova em projeto atrasado quase sempre atrasa mais, porque as primeiras semanas de qualquer dev novo são de contexto, não de entrega. Se o barco está afundando, renegocie prazo com o cliente antes de contratar remador.

Quanto repassar: a matemática da margem

Aqui é onde a maioria erra, então vamos com números. Suponha um projeto de R$ 50 mil, 10 semanas, e você quer repassar metade da execução.

• Bloco repassado: representa uns R$ 25 mil do contrato.
• Repasse justo para o dev parceiro: R$ 15 mil a R$ 17 mil (60% a 68%).
• Sua margem no bloco: R$ 8 mil a R$ 10 mil.

Parece muito? Não é. Essa margem paga o que você continua fazendo: vender o projeto (foi você que fechou), gerenciar o cliente (reunião, cobrança de feedback, expectativa), revisar o código, e principalmente absorver o risco. Se o dev parceiro sumir, o contrato tem o seu nome. Se der bug em produção, é o seu telefone que toca. Margem de repasse não é comissão, é seguro mais gestão.

Do outro lado, se você espremer o parceiro para 40% do valor do bloco, ele vai aceitar apertado, priorizar outro cliente no meio do caminho e entregar no limite. Repasse mal pago é a receita mais rápida para retrabalho.

Contrato com o subcontratado: o que não pode faltar

Você tem contrato com o cliente. Precisa de contrato com o dev também, mesmo que ele seja seu amigo. Principalmente se ele for seu amigo. As cláusulas que salvam:

1. Escopo espelhado. O que o dev vai entregar tem que ser um subconjunto claro do que você prometeu ao cliente, com os mesmos critérios de aceite. Se o seu contrato com o cliente diz "checkout com Pix e cartão", o contrato com o parceiro não pode dizer só "módulo de pagamento".
2. Prazo com folga. O prazo do parceiro deve fechar antes do prazo com o cliente. Uma a duas semanas de buffer para revisão e ajuste. Prazo espelhado sem folga é aposta, não planejamento.
3. Propriedade intelectual. Todo código produzido pertence a você (e por consequência ao cliente final) após o pagamento. Sem isso, você pode ficar refém.
4. Não aliciamento. O parceiro não aborda o seu cliente diretamente por um período (12 a 24 meses é o padrão de mercado). Isso protege os dois lados e deixa a relação limpa.
5. Pagamento vinculado a marco, não a data. Você paga quando o bloco passa no aceite, não quando o calendário vira. E de preferência depois que o pagamento correspondente do cliente entrou.

Como gerenciar sem virar gargalo

O erro clássico do freelancer que subcontrata pela primeira vez: microgerenciar tudo e virar o gargalo do próprio projeto. Ou o oposto, sumir e descobrir o problema na semana da entrega. O meio termo que funciona:

• Um checkpoint fixo por semana. Call de 30 minutos ou update assíncrono estruturado: o que foi feito, o que vem, o que está travado. Sem isso você só descobre atraso quando já estourou.
• Code review desde a primeira semana. Não espere o bloco pronto para olhar o código. Um PR ruim na semana 1 custa uma conversa; dez PRs ruins na semana 6 custam o projeto.
• Você é a única interface com o cliente. O parceiro não fala com o cliente, e o cliente não precisa saber a estrutura interna do time. Isso não é esconder nada, é ter um ponto único de responsabilidade. Na OCA fazemos igual: um responsável fala com o cliente, mesmo quando a execução é distribuída.
• Ambiente e acesso no dia zero. Repositório, staging, credenciais, documentação do que existe. Cada dia que o parceiro passa esperando acesso é dinheiro seu evaporando.

Os erros que quebram quem subcontrata

Situações reais que eu já vi (e algumas que eu vivi):

• Pagar antes de receber. Você adianta o parceiro, o cliente atrasa o pagamento, e agora você financiou o projeto do próprio bolso. Alinhe o fluxo de caixa: sinal do cliente cobre o início do parceiro, marco cobre marco.
• Repassar sem testar o dev. Portfólio bonito não é entrega. Antes de confiar um bloco de R$ 20 mil, comece com uma tarefa pequena e paga. Uma semana de trabalho real diz mais que três entrevistas.
• Assumir que o parceiro entende o contexto. Ele não participou da venda, não conhece o cliente, não sabe o que foi prometido. Escreva um briefing decente: objetivo do projeto, decisões já tomadas, o que é inegociável. Trinta minutos escrevendo economizam semanas de retrabalho.
• Esconder do cliente que existe um time. Você não precisa apresentar cada pessoa, mas mentir que faz tudo sozinho cobra caro quando o cliente pede uma call técnica e você não sabe detalhe da implementação. Fale em "meu time" ou "meus parceiros" desde a proposta.

O caminho inverso: ser o dev que recebe projeto repassado

Tudo que eu descrevi até aqui tem um espelho. Se existe freelancer com demanda sobrando e precisando de gente confiável, existe espaço para o dev que entrega bem mas não tem pipeline. Isso não é teoria, é literalmente como a OCA cresceu. A gente aparece no Google e nas IAs para buscas de desenvolvimento de software no Brasil, e isso traz dezenas de leads de clientes por dia, mais do que o time consegue atender. A resposta foi montar uma rede de parceiros: devs seniores e times pequenos que recebem projetos já vendidos, com escopo fechado e cliente validado.

Do lado de quem recebe, o jogo muda: você pula a parte mais cara do freelance, que é conseguir o cliente, e entra direto na execução. Em troca, o que se espera é o mesmo que você esperaria do seu subcontratado: entrega no prazo, comunicação em dia, código que passa em revisão. Se você já entrega bem, o seu problema não é técnico, é distribuição. E distribuição dá para resolver dos dois jeitos: construindo a sua máquina de leads, ou se conectando a quem já tem uma.

Entre para a rede de parceiros da OCA

O próximo passo desta semana

Independente de entrar em rede nenhuma, faça isto: monte hoje o seu contrato padrão de subcontratação com as cinco cláusulas acima. Mesmo que você ainda não tenha ninguém para subcontratar. Porque quando o projeto grande aparecer, e ele aparece sem avisar, a diferença entre aceitar com segurança e recusar por medo vai ser um documento que você podia ter escrito numa tarde.

E se quiser ver o tipo de projeto que circula por aqui, o portfólio da OCA mostra o padrão do que a gente constrói e repassa.