Cobrar por hora ou por projeto no freelance dev: qual modelo usar em cada caso (e por que a OCA fecha por escopo)

Você entrega bem. O cliente pergunta quanto custa, você responde "cobro R$ 150 a hora", e uma de duas coisas acontece. Ou ele some, porque não faz ideia de quantas horas aquilo dá e ficou com medo da conta aberta. Ou ele fecha e passa a auditar cada minuto: "isso levou 6 horas mesmo?", "por que a reunião entrou na fatura?". Nos dois cenários, você virou fornecedor de tempo, não de resultado. E o pior: quanto mais rápido você fica, menos você ganha por projeto.

Vou te falar como funciona do lado de quem recebe os leads: a pergunta "quanto custa" chega dezenas de vezes por dia na OCA, e quase nenhum cliente quer saber a sua hora. Ele quer saber quanto custa o problema dele resolvido. O modelo de cobrança que você escolhe decide se essa conversa fecha ou morre.

Por que cobrar por hora pune o dev que é bom

A conta é simples. Um dev júnior leva 200 horas para fazer um app de agendamento. Você, com sete anos de estrada e um boilerplate de Expo pronto, faz em 80. Se os dois cobram por hora, o júnior fatura mais que você no mesmo projeto. Sua experiência virou desconto para o cliente.

Cobrar por hora ainda cria dois problemas que ninguém conta no começo:

• O cliente não consegue comparar. R$ 150 a hora contra R$ 90 a hora de outro dev parece caro, mesmo que o outro leve o triplo de horas. O cliente compara o número que ele entende.
• Todo incentivo fica torto. Você ganha mais se demorar. O cliente sabe disso e vira fiscal. A relação começa desconfiada.

Isso não quer dizer que hora nunca serve. Quer dizer que hora é uma ferramenta para situações específicas, não o padrão.

Os três modelos de cobrança e quando cada um faz sentido

Por hora (ou por dia)

Você registra tempo e fatura no fim do período. Faz sentido quando o escopo não existe ainda ou não dá para conhecer: código herdado que você nunca abriu, investigação de bug em produção, um cliente técnico que te aloca como parte do time dele. Faixa sênior no Brasil em 2026: R$ 120 a R$ 250 por hora, dependendo de stack, nicho e senioridade. Se cobrar por hora, sempre coloque teto: "até 40 horas, aviso quando chegar em 30".

Por projeto (escopo fechado)

Preço fixo por uma entrega definida. É o modelo que a OCA usa em praticamente todo projeto que fecha e repassa. Funciona quando existe briefing, lista de funcionalidades e critério claro de "pronto". O cliente sabe quanto vai gastar, você ganha pela eficiência, e a conversa de venda vira "isso resolve o seu problema por X", não "quantas horas você acha que vai levar".

Retainer mensal

Valor fixo por mês por disponibilidade e um pacote de horas ou entregas. Serve para manutenção e evolução contínua depois que o produto está no ar. Já escrevi sobre como estruturar esse modelo aqui no blog, então não vou repetir. O ponto é: retainer é a continuação natural de um projeto fechado que deu certo.

Como converter sua estimativa em preço por projeto

O medo de todo dev ao fechar por projeto é o mesmo: "e se eu estourar as horas?". A resposta não é voltar para a hora. É precificar direito. O caminho que uso na OCA:

1. Estime por funcionalidade, não pelo projeto inteiro. "App de agendamento" não é estimável. "Login com Google, agenda com slots, notificação push, painel admin" é.
2. Aplique a margem de erro. Estimativa de dev estoura. Multiplico por 1,3 em projeto de escopo bem definido e por 1,5 quando o cliente ainda muda de ideia na reunião. Isso não é gordura, é a estatística do seu próprio histórico.
3. Multiplique pela hora que você quer ganhar, não pela que você aceita. Se o seu alvo é R$ 180 e a estimativa deu 80 horas, o preço base é 80 x 1,3 x 180 = R$ 18.720.
4. Cruze com o valor para o cliente. Se esse app vai substituir duas pessoas organizando agenda no WhatsApp, R$ 18 mil se paga em meses. Se é o projeto de fim de semana de alguém, o número não fecha, e é melhor descobrir agora do que na terceira reunião.
5. Escreva o que não está incluso. Essa lista vale mais que a lista do que está. É ela que transforma "preço fechado" de aposta em contrato.

Na OCA a gente aplica isso em todo orçamento que sai. O próprio Revo, que hoje tem mais de 40 mil usuários, foi construído em ciclos de escopo fechado: cada versão com lista de funcionalidades e critério de pronto antes de começar. Foi assim que a gente aprendeu a fazer o mesmo para cliente. Isso não é teoria, é literalmente como a OCA cresceu.

Quando o cliente insiste em hora (e o que responder)

Alguns clientes pedem hora porque querem comparar com outro dev mais barato. Outros porque já se queimaram com projeto fechado que virou briga de "isso não estava no escopo". Os dois motivos são legítimos e têm resposta:

• "Quero comparar com outra proposta." Compare entregas, não horas: "Meu preço inclui X, Y e Z, com deploy e duas semanas de garantia. Vale conferir se a outra proposta cobre o mesmo." Se ele comparar só o número da hora, o problema é o cliente, não o seu preço.
• "Já paguei projeto fechado e o dev sumiu." Ofereça marcos com pagamento por entrega. Ele paga 30% no início, 40% na primeira versão navegável, 30% na publicação. Escopo fechado com marcos protege os dois lados.
• "Não sei o que quero ainda." Aí a hora faz sentido, mas com teto e com nome: uma fase de descoberta paga, curta, que termina com escopo escrito. Depois disso, projeto fechado.

As armadilhas que quebram o freelancer em cada modelo

• Projeto fechado com escopo aberto. "Um app tipo iFood" a preço fixo é a forma mais rápida de trabalhar de graça por três meses. Sem lista de funcionalidades e critério de pronto, você não fechou preço, fechou uma aposta.
• Hora sem teto e sem relatório. Cliente ansioso, fatura surpresa, briga no fim do mês. Se é por hora, mande resumo semanal de horas e do que foi feito. Silêncio mata contrato.
• Dar desconto na hora. Se você cede de R$ 180 para R$ 120 na primeira conversa, o cliente aprendeu que seu preço é negociável. No projeto fechado, desconto sai do escopo, nunca do preço: "dá para chegar nesse valor tirando o painel admin da primeira versão".
• Misturar modelos sem escrever. Projeto fechado com "ah, essas alterações eu cobro por hora" combinado por áudio no WhatsApp vira discussão. Mudança de escopo tem processo e tem texto. Sem isso, você absorve.
• Precificar pela hora que você aceita. Quem vem de CLT tende a dividir o salário por 160 e usar isso como hora. Essa conta ignora imposto, férias, tempo não faturável e o custo de vender. A hora que você quer costuma ser o dobro da que você calcula no susto.

Como isso funciona nos projetos que a OCA repassa

Hoje chegam mais leads na OCA do que a gente consegue atender. Por isso a gente mantém uma rede de devs sêniores e times pequenos que recebem projetos já vetados. E aqui o modelo de cobrança importa muito: todo projeto repassado chega com escopo escrito, preço fechado e marcos de entrega. O parceiro não precisa negociar hora com o cliente nem justificar fatura. Ele precisa de uma coisa só: entregar dentro do escopo combinado, no prazo, com qualidade de produção.

O que a gente olha antes de repassar é justamente se o dev sabe trabalhar assim. Quem só cobrou por hora a vida inteira costuma ter dificuldade em dizer "isso não está no escopo" com educação e firmeza. Quem já fechou projeto por escopo sabe que essa frase é o que protege a margem dele e a relação com o cliente.

Se você já entrega bem, o seu problema não é técnico, é distribuição. E parte da distribuição é falar de preço de um jeito que o cliente entende.

Entre para a rede de parceiros da OCA

O que fazer esta semana

Pegue o último orçamento que você mandou por hora. Reescreva como projeto fechado: lista de funcionalidades, critério de pronto, três marcos de pagamento e uma seção "não incluso". Compare o número final com o que você mandou. Na maioria das vezes o preço fechado é maior, e ainda assim mais fácil de o cliente dizer sim. Se quiser ver como a gente apresenta isso na prática, os projetos no portfólio da OCA foram todos fechados por escopo.