Eu recusei um contrato de R$ 1,2 milhão. Faria de novo.

Outubro de 2025: chega no meu WhatsApp o que seria o maior contrato da história da Revin. Seis devs, doze meses, escopo aberto. Eu li duas vezes e disse não. Aqui eu conto o que tinha naquela proposta, por que comprar hora de dev é o jeito mais caro de construir software, e o que aconteceu depois.

Por Victhor Araújo

Victhor Araújo

Outubro de 2025, uma quinta-feira no fim da tarde. Chega no meu WhatsApp uma proposta que seria, na época, o maior contrato da história da Revin: R$ 1,2 milhão em doze meses. Seis desenvolvedores, início imediato, "a gestão a gente faz por aqui".

Li o escopo duas vezes e pedi uma call. Na call, agradeci e disse que não íamos fazer. O sócio do outro lado ficou uns três segundos em silêncio e perguntou se eu tinha entendido o valor. Tinha entendido.

Esse texto é sobre o que eu vi naquela proposta. E sobre por que comprar hora de dev é o jeito mais caro de construir software, mesmo quando a planilha diz o contrário.

A proposta era bonita no papel. O papel, como sempre, aceita qualquer coisa.

O que tinha na proposta

Seis desenvolvedores "alocados", daily comandada pelo head de produto deles, backlog numa planilha com 214 linhas e uma frase que eu guardei até hoje: "o escopo a gente fecha andando". O head de produto, diga-se, nunca tinha gerido um time de engenharia na vida. Gente boa, inteligente, genuinamente empolgada com o produto. Mas nunca tinha feito aquilo.

Não tinha definição de pronto. Não tinha critério de aceite. Não tinha dono técnico. Tinha seis cadeiras e um cronograma de pagamento mensal, pontualíssimo.

No papel, era staff augmentation clássico. Na prática, era bodyshop com crachá novo: cadeira ocupada, responsabilidade de ninguém. E bodyshop a Revin não vende. Nunca vendeu.

Eu já vi esse filme (três vezes, pra ser exato)

Quando você compra hora, o fornecedor é pago por presença, não por resultado. O incentivo dele passa a ser manter a cadeira ocupada. Ninguém fala isso em voz alta, claro. Mas o roteiro é sempre o mesmo:

• Mês 1 a 3: lua de mel. Velocity alta, demo bonita, todo mundo se elogiando no Slack.
• Mês 4: uma decisão técnica empaca esperando alguém que não sabe decidir. O time começa a "adiantar outras coisas".
• Mês 6: trocam um dev "pra otimizar custo". O conhecimento do sistema vai embora junto com ele.
• Mês 9: alguém do board sugere uma auditoria externa. É o atestado de óbito do projeto.

Eu sei porque a Revin já foi chamada três vezes pra fazer exatamente essa auditoria do mês 9. Na última, num cliente de logística, encontramos 11 mil linhas de código sem um teste sequer e um deploy que dependia do notebook de um dev específico. Eu queria estar exagerando.

Se a sua operação está em algum desses meses, o Diagnostic Sprint da Revin faz em duas semanas o que a auditoria do mês 9 faz tarde demais: código aberto na mesa e um relatório que o seu CFO entende.

🧾 A conta que ninguém faz na frente do cliente

R$ 1,2 milhão por seis devs em doze meses dá R$ 16,6 mil por dev por mês. Pra sênior nearshore, é preço honesto. O preço nunca foi o problema. O problema é o retrabalho que não aparece na planilha.

Nos projetos que a gente resgatou nos últimos dois anos, o retrabalho médio dos primeiros seis meses foi de 38%. Aplica isso nos R$ 1,2 milhão: são R$ 456 mil construindo a coisa errada, ou construindo a coisa certa duas vezes.

Quase meio milhão. Pra economizar um tech lead.

A calculadora aceita qualquer cenário. O retrabalho não aparece em nenhum deles.

O que a gente ofereceu no lugar

Contra-proposta: squad de quatro pessoas com tech lead, ritual completo (planning, review semanal com stakeholder, relatório quinzenal pro board) e entrega por fases, com definição de pronto escrita antes da primeira sprint. R$ 870 mil no ano. Menos gente, menos dinheiro pra mim, mais software funcionando pra eles.

Pra ser justo: existe cenário em que comprar hora funciona. Se você tem CTO forte, processo de engenharia rodando e só precisa de braço por uns meses, staff augmentation resolve e sai mais barato. Esse cliente não tinha nada disso. E a real é que a maioria não tem.

Eles não fecharam. Foram com uma agência que aceitou o modelo do jeito que estava, seis cadeiras e tudo.

O epílogo, porque sempre tem um

Em março deste ano, o mesmo sócio me chamou de novo. O projeto estava "pausado para reavaliação". Ele perguntou se a proposta do squad ainda estava de pé. Estava. Começamos em julho, com o squad de quatro.

Não conto essa história pra posar de íntegro. Conto porque o mercado ensinou founder a comprar software como commodity: por hora e por cabeça. Software não é commodity. Quem te vende cadeira ocupada não está do seu lado, por mais simpático que seja na call.

Se você está decidindo entre os dois modelos agora, a gente escreveu uma comparação honesta, com os cenários em que cada um ganha: squads gerenciados vs. staff augmentation.

E se quiser uma opinião sobre o seu caso específico, agenda 30 minutos comigo. Sem slide e sem pitch: eu atendo essas conversas pessoalmente.