Subcontratar outro dev no freelance: como montar uma microequipe sem perder margem nem cliente (a conta do repasse e o contrato em cadeia de 2026)

Você entrega bem. Os clientes voltam e indicam, e agora aparece um problema que parecia bom de ter: tem mais projeto do que hora. O terceiro orçamento do mês chega e você sabe que, se aceitar, vai atrasar os outros dois. Recusar dói, porque é dinheiro e é relacionamento.

Aí vem a ideia óbvia: chamar aquele amigo da faculdade, ou o dev que trabalhou com você na última empresa, e dividir o trabalho. Só que surgem as perguntas que ninguém responde direito. Quanto eu pago para ele? Quanto eu cobro do cliente? Se ele sumir no meio, quem responde? O código é de quem? O cliente precisa saber?

Este artigo é sobre esse momento, quando o dev solo vira microequipe. Tem a conta, o contrato e os erros que eu vi acontecerem, alguns comigo.

Quando você repassa um projeto, você para de vender hora e passa a vender entrega

Muito dev encara a subcontratação como “eu fico com uma parte sem fazer nada”. É essa leitura que quebra a primeira tentativa.

No momento em que outro dev escreve o código do seu cliente, três coisas mudam:

• O risco continua seu. Se o subcontratado atrasar, entregar com bug ou desaparecer, o cliente cobra você. O contrato com o cliente está no seu CNPJ.
• Seu trabalho muda de natureza. Você programa menos e passa a vender, escopar, revisar código, testar e falar com o cliente. Isso também é trabalho, consome hora e precisa ser pago.
• O cliente comprou o seu padrão de qualidade. Ele fechou com você porque confiou em você. Se o padrão cair, a próxima indicação não vem.

Então a margem que fica com você não é comissão. Ela paga a venda, a gestão e o risco. Se não cobre essas três coisas, você está trabalhando de graça e com mais estresse.

A conta do repasse: quanto da margem fica com você de verdade

A conta é simples, mas tem duas linhas que quase todo mundo esquece. Vamos a um exemplo de projeto médio: um sistema web estimado em 200 horas.

A linha do imposto

Você emite nota do valor inteiro para o cliente e recebe a nota do subcontratado. No Simples Nacional, o imposto incide sobre o seu faturamento, não sobre a sua margem. Ou seja, os R$ 22.000 que só passam pela sua conta também pagam imposto e ainda empurram você para faixas mais altas do Simples ao longo do ano. Tem outro detalhe: pagamento a PJ não conta como folha. Mais faturamento sem aumentar seu pró-labore pode derrubar seu Fator R para menos de 28% e jogar você do Anexo III para o Anexo V. Confirme com o seu contador antes de fechar o primeiro repasse.

A linha das suas horas

Nesse cenário, R$ 200 por hora parece ótimo. Agora imagine que o subcontratado entregou um módulo que precisou ser refeito, e você gastou mais 30 horas revisando, corrigindo e acalmando o cliente. São 70 horas para os mesmos R$ 8.080, cerca de R$ 115 por hora. Provavelmente menos do que você cobraria programando sozinho.

Por isso, estas são as faixas que funcionam na prática:

• Margem de 25% a 40% sobre o preço do cliente. Abaixo de 20%, o primeiro retrabalho come tudo.
• Reserve de 15% a 25% das horas do projeto para você. Gestão, code review, testes e reuniões. Se você não reservar, vai fazer de graça.
• Repasse só projeto a partir de uns R$ 10 mil. Abaixo disso, briefing e alinhamento custam quase a mesma coisa e a margem some.

Esses números mudam com a senioridade do subcontratado, com o quanto o escopo está definido e com quanta reunião o cliente pede. Escopo vago pede margem maior, não menor.

Como escolher e testar o segundo dev antes de entregar um projeto inteiro

Isso não é teoria, é literalmente como a OCA cresceu. A gente aparece no Google e nas IAs quando alguém pesquisa desenvolvimento de software, e faz tempo que a demanda passou da capacidade do time. A única forma de não recusar quase tudo foi aprender a repassar sem perder o padrão. O processo que sobreviveu foi este:

1. Escolha por histórico de entrega, não pela hora mais barata. Quero ver um projeto que a pessoa terminou, com código que eu consiga ler: repositório público, PR revisado, sistema em produção. Hora barata com retrabalho sai cara.
2. Comece com uma tarefa pequena e paga. De 8 a 16 horas, com escopo fechado e prazo. Você paga mesmo se não gostar do resultado. Em uma semana você descobre como a pessoa se comunica, se cumpre prazo e se o código passa no seu review.
3. Escreva um briefing de repasse de uma página. Objetivo do projeto, o que está dentro e fora do escopo, stack e padrões (lint, estrutura de pastas, convenção de commits), critério de aceite por entrega, datas e valor. Se você não consegue escrever essa página, o escopo ainda não está pronto para ser repassado.
4. Code review em todo PR. Nada entra na branch principal sem você ler. É para isso que servem as horas reservadas para você, e é isso que mantém o padrão que o cliente comprou.
5. Um canal só com o cliente: você. O subcontratado pode até participar de uma reunião técnica, mas decisão de escopo, prazo e preço passa por você. Dois canais viram dois escopos.
6. Faça o update semanal com o subcontratado antes do update com o cliente. Você precisa saber do atraso na segunda, não quando o cliente perguntar na sexta.

Sobre transparência: avise o cliente que você trabalha com parceiros sob sua responsabilidade técnica. Esconder costuma dar errado no dia em que aparece um commit com outro nome. Quando você deixa isso claro e diz que responde pela entrega, a confiança costuma aumentar.

Os erros que transformam microequipe em prejuízo

• A cadeia de direitos quebrada. Seu contrato com o cliente cede o código a ele depois do pagamento. Só que quem escreveu o código foi o subcontratado, e o contrato com ele não tem cláusula de cessão de direitos patrimoniais para você. A Lei do Software (9.609/98) tende a favorecer quem contrata, mas isso depende de como o contrato descreve o serviço. Não aposte em interpretação: escreva a cessão no contrato de subcontratação, com o mesmo gatilho do contrato do cliente.
• Pagar o subcontratado só quando o cliente pagar, sem ter combinado isso. Se o cliente atrasa e você segura o pagamento do dev sem isso estar escrito, você perde o parceiro. Decida antes: ou o pagamento dele acompanha os marcos do cliente, com isso no contrato, ou você paga quando a entrega for aceita e assume o risco de caixa. Os dois modelos funcionam. Pegar o parceiro de surpresa, não.
• Escopo que cresce e só você absorve. O cliente pede um extra, você aceita para manter a relação, e o subcontratado cobra as horas a mais de você. Sem um fluxo de change request repassado ao cliente, o extra sai da sua margem.
• Subcontratado falando direto com o cliente. Começa com uma dúvida técnica e termina com o cliente pedindo funcionalidade nova ao dev, que aceita para agradar. Coloque no contrato a regra de canal único e uma cláusula de não aliciamento de 12 meses.
• Repassar projeto que você não entende. Se você não domina a stack ou o domínio, não consegue revisar nem estimar. Você vira um intermediário caro, e o cliente percebe.
• Parar de programar cedo demais. Quem só gerencia e não põe a mão no código perde o padrão em poucos meses. No começo, fique com pelo menos uma parte técnica crítica.

Como a OCA faz isso em escala e onde você pode entrar

Vou te falar como funciona do lado de quem recebe os leads: chegam dezenas de pedidos de clientes por dia, mais do que o time da OCA consegue atender. Tudo o que está acima é o que a gente pratica com a nossa rede de parceiros, formada por devs seniores e pequenas equipes que recebem projetos já qualificados e escopados.

O que a OCA espera de um parceiro:

• Histórico de entrega verificável, com código para ler.
• Contrato assinado, com cessão de direitos e confidencialidade.
• Update semanal e PRs que dê para revisar.
• Relação com o cliente intermediada pela OCA, sem atalhos.

O que o parceiro recebe:

• Projeto com escopo, preço e critério de aceite definidos antes de começar.
• Cliente já qualificado, sem prospecção nem proposta da sua parte.
• Pagamento por marcos, combinado por escrito.

Sendo direto: para entrar na rede tem uma avaliação, e não existe volume garantido de projetos. O repasse depende de aparecer um projeto que combine com a sua stack e com a sua disponibilidade. Se você já entrega bem, o seu problema não é técnico, é distribuição. A rede é uma das formas de resolver isso enquanto você monta a sua própria máquina. Para ver o tipo de produto que a OCA constrói, dê uma olhada na página de projetos da OCA.

O próximo passo desta semana

Entrando na rede ou não, faça isto antes de aceitar o próximo projeto que passa da sua capacidade: escreva o briefing de repasse de uma página para um projeto que você já tem. Objetivo, o que está dentro e fora do escopo, padrões de código, critério de aceite, datas e valor. Depois refaça a conta da tabela com os seus números reais, incluindo o imposto sobre a nota cheia e 20% das horas para você. Se a margem final ficar abaixo do que você ganha programando sozinho, o problema é o preço que você cobra do cliente, não o repasse.

Se você quer receber projetos que já chegam escopados, me manda uma mensagem:

Entre para a rede de parceiros da OCA