Parceria com software house: como funciona receber projetos repassados e o que fazer para ser escolhido

Você entrega bem. Seu código passa em review, seus prazos fecham, seus clientes antigos falam bem de você. Mesmo assim, tem mês que o pipeline é zero. Você abre o LinkedIn, pensa em postar alguma coisa, desiste, responde dois recrutadores de vaga CLT que você não quer e fecha a aba. O problema não é a sua entrega. É que ninguém te encontra, e prospectar cliente do zero é um segundo emprego que você não pediu.

Existe um caminho no meio disso que pouca gente explica direito: receber projetos repassados por quem já tem demanda de sobra. Vou te falar como funciona do lado de quem recebe os leads, porque é exatamente a posição da OCA hoje.

Por que uma software house repassa projeto em vez de contratar mais gente

A conta é simples. A OCA aparece no Google e nas respostas de IAs como ChatGPT e Perplexity para buscas de desenvolvimento de software no Brasil. Isso gera dezenas de leads de clientes por dia. Nenhum time enxuto dá conta desse volume, e crescer contratando destrói justamente o que faz o modelo funcionar: time senior, pequeno, com acesso direto a quem escreve o código.

Contratar um dev CLT para absorver pico de demanda é um risco fixo para resolver um problema variável. Recusar o lead é queimar dinheiro e reputação. A terceira opção é repassar o projeto para alguém de confiança, com escopo fechado e expectativa alinhada. Todo mundo ganha: o cliente é atendido, o parceiro recebe um projeto que ele nunca teria prospectado sozinho, e a software house mantém a máquina girando sem inchar.

Isso não é teoria, é literalmente como a OCA cresceu. E não é um modelo exclusivo nosso: agências, consultorias e outras software houses no Brasil inteiro operam assim, muitas vezes sem chamar isso de "rede de parceiros".

O que chega até o parceiro: anatomia de um projeto repassado

Um projeto repassado decente não é um encaminhamento de WhatsApp com "fala com esse cara aí". Quando o repasse é bem feito, o parceiro recebe:

• Lead qualificado. Alguém já conversou com o cliente, filtrou curioso de comprador e confirmou que existe orçamento real.
• Escopo delimitado. O que entra, o que não entra, e o que vira aditivo se aparecer no meio do caminho.
• Faixa de preço validada. O cliente já ouviu um número e não caiu da cadeira. Você não vai gastar duas semanas em proposta para ouvir "achei que era uns 3 mil".
• Expectativa de prazo e stack. Se o projeto é um app em React Native com backend em Node, você sabe antes de aceitar.

Compare com o ciclo de prospecção tradicional: achar o lead, qualificar, reunião de descoberta, proposta, follow-up, negociação. São semanas de trabalho não pago com taxa de conversão baixa. No repasse, você entra no ponto em que o cliente já decidiu comprar.

Quanto se ganha em projeto repassado: a conta honesta

Ninguém repassa projeto de graça, e você não deveria esperar isso. Os modelos mais comuns no mercado brasileiro:

1. Comissão sobre o projeto. Quem originou o lead fica com um percentual, geralmente entre 10% e 20%, e o parceiro executa e fatura o resto. É o modelo mais transparente.
2. Subcontratação. A software house fecha com o cliente e contrata o parceiro por valor fechado ou por hora. O parceiro não aparece para o cliente final. Margem menor, risco menor: quem responde pelo projeto é quem fechou.
3. Repasse integral com fee fixo. O cliente vira seu, com contrato direto, e você paga um valor único pela originação. Mais raro, mas existe.

Antes de reclamar da comissão, faça a conta do custo de aquisição. Se você gastaria 20 ou 30 horas prospectando e vendendo para fechar um projeto de R$ 40 mil, uma comissão de 15% (R$ 6 mil) provavelmente sai mais barato que o seu tempo, e vem sem o risco de não fechar nada. Se você já entrega bem, o seu problema não é técnico, é distribuição. Comissão de repasse é o preço da distribuição.

O que quem repassa avalia antes de confiar um projeto a você

Aqui vale ser radicalmente transparente, porque é a parte que ninguém conta. Quando a OCA avalia um dev ou um time pequeno para a rede de parceiros, o critério técnico é o filtro de entrada, não o diferencial. O que realmente decide:

Comunicação previsível

O maior medo de quem repassa não é bug, é silêncio. Um parceiro que some por cinco dias queima a reputação de quem indicou. Status curto e regular, mesmo que seja "essa semana travei no X, resolvo até sexta", vale mais que qualquer certificação.

Histórico de entrega, não de código bonito

Portfólio com projeto em produção, com usuário de verdade usando, pesa mais que repositório impecável no GitHub. Queremos saber: você já levou algo até o fim? Já sustentou um sistema depois do deploy? Já lidou com cliente mudando de ideia na semana da entrega?

Maturidade comercial

Parceiro que aceita escopo aberto, não formaliza aditivo e depois quer renegociar no meio do projeto vira problema para todo mundo. Quem repassa procura gente que entende que contrato, marco de pagamento e escopo cercado protegem os dois lados.

Estrutura mínima de PJ

CNPJ ativo, capacidade de emitir nota fiscal, conta PJ. Sem isso o repasse formal simplesmente não acontece, porque a cadeia fiscal precisa fechar.

As armadilhas do modelo (dos dois lados)

Nem todo repasse é bom negócio. Situações que a gente já viu dar errado:

• O repasse de batata quente. Projeto que a software house recusou porque o cliente é problemático, o escopo é indomável ou o orçamento não fecha. Se quem repassa não quis o projeto para si, pergunte por quê, e pergunte de novo se a resposta for vaga.
• Comissão sem contrato. Acordo de percentual fechado por áudio no WhatsApp. Quando o projeto cresce, a memória encolhe. Formalize o modelo de repasse por escrito antes da primeira linha de código.
• Responsabilidade mal definida. Se o cliente liga às 22h com o sistema fora do ar, quem atende? No modelo de subcontratação, quem fechou responde. No repasse integral, é você. Saiba em qual dos dois você está antes de aceitar.
• Depender de uma única fonte de repasse. Trocar a dependência de plataforma gringa pela dependência de um único parceiro é trocar de gaiola. Rede de parceiros deve ser um canal do seu pipeline, não o pipeline inteiro.

Como entrar no radar de quem tem demanda sobrando

Você não precisa esperar convite. Passos práticos que aumentam sua chance de receber repasse, de qualquer software house ou agência:

1. Deixe sua entrega verificável. Um case escrito por projeto: problema, solução, stack, resultado. Duas ou três frases por item. É isso que quem repassa manda para o cliente quando apresenta você.
2. Declare sua faixa de atuação. Stack, tipo de projeto e ticket em que você é bom. "Faço tudo" gera desconfiança; "apps React Native com backend Node, projetos de R$ 30 a 100 mil" gera repasse certeiro.
3. Arrume a casa jurídica. CNPJ adequado, modelo de contrato próprio, clareza sobre nota fiscal. Parceiro que resolve a burocracia em um dia passa na frente de quem "vai ver isso".
4. Cultive relação antes de precisar. Comente trabalho de software houses que você respeita, indique lead que não é seu perfil para elas. Quem indica primeiro entra na lista de quem recebe depois.

Como funciona na OCA

Do nosso lado, o fluxo é direto: o lead chega pelo blog, pelo Google ou por indicação, a gente qualifica, fecha escopo e faixa de preço com o cliente, e projetos que não cabem na nossa agenda vão para parceiros da rede que batem com o perfil do projeto. O parceiro recebe o contexto completo antes de aceitar, e ninguém é obrigado a pegar nada.

O que a gente espera de um parceiro é o que descrevi acima: entrega comprovada, comunicação previsível e maturidade para trabalhar com escopo e contrato. O que o parceiro recebe é projeto qualificado, com cliente que já decidiu comprar, sem gastar uma hora em prospecção. Sem promessa de volume: a demanda existe e é real, mas repasse depende de encaixe entre projeto e perfil.

Se esse modelo faz sentido para o momento da sua carreira, o caminho é uma conversa:

Entre para a rede de parceiros da OCA

E independente da OCA, uma ação para essa semana: escreva o case de um projeto seu que está em produção, no formato problema, solução, stack e resultado. É a peça que destrava qualquer conversa de repasse, com a gente ou com qualquer outra software house. Se quiser referência de formato, veja como a OCA apresenta os projetos do próprio portfólio.