Preço fechado ou por hora: como cobrar um projeto freelance sem sair no prejuízo

Você fechou o valor do projeto em R$ 12 mil. Estimou seis semanas. Na semana oito, ainda está ajustando "detalhes" que o cliente jura que estavam combinados. Divide o total pelas horas reais e descobre que está ganhando menos que um estágio. Do outro lado, tem o dev que cobra por hora, manda o timesheet no fim do mês e ouve: "Como assim 40 horas nisso? Meu sobrinho fazia em 10."

Os dois modelos podem dar certo e os dois podem te quebrar. A diferença não está no modelo, está em quem carrega o risco de estimativa. Vou te falar como funciona do lado de quem recebe os leads: na OCA a gente orça projeto toda semana, e a escolha entre preço fechado e hora é uma das primeiras decisões de cada proposta. Errar essa escolha custa mais que errar a estimativa.

A verdade desconfortável: você não vende horas nem entregas, vende risco

Todo projeto de software tem incerteza: requisito que muda, integração que não funciona como a documentação promete, cliente que descobre o que quer vendo a primeira versão. Alguém paga por essa incerteza. A única pergunta é quem.

• Preço fechado: o risco é seu. Se estourar, você trabalha de graça. Em troca, o cliente aceita pagar um valor maior pela previsibilidade.
• Por hora: o risco é do cliente. Se estourar, ele paga mais. Em troca, ele quer visibilidade e tende a questionar cada hora.

Quem cobra preço fechado sem colocar margem de risco está subsidiando a incerteza do cliente com o próprio bolso. Quem cobra por hora sem combinar teto e cadência de reporte está pedindo para virar suspeito. A conta é simples: modelo sem gestão de risco é prejuízo com data marcada.

Quando preço fechado funciona (e quando é armadilha)

Preço fechado funciona quando você consegue estimar com confiança. Isso exige três condições ao mesmo tempo:

1. Escopo escrito e fechado. Não é "um app de delivery", é uma lista de telas, fluxos e integrações com nome e sobrenome. O que não está na lista, não está no preço.
2. Território conhecido. Você já construiu algo parecido. Se é sua primeira integração com aquele gateway de pagamento ou aquele ERP, sua estimativa é chute.
3. Cliente que decide. Uma pessoa aprova, responde em prazo razoável e não reabre decisão fechada. Comitê que muda de ideia toda sprint destrói qualquer preço fechado.

Se as três condições existem, preço fechado é o melhor modelo para você: cliente adora previsibilidade, e a eficiência vira sua margem. Terminou em quatro semanas o que precificou em seis? A diferença é lucro, não desconto.

A armadilha clássica: fechar preço em cima de um briefing de duas linhas porque o cliente "precisa do número para amanhã". Número dado em cima de escopo vago vira teto na cabeça do cliente e piso na sua planilha de horas. Na OCA, projeto sem escopo claro não recebe preço fechado, recebe uma fase de descoberta paga ou uma faixa larga com condições explícitas.

Quando cobrar por hora é o único modelo honesto

Existem projetos em que preço fechado é mentira educada, porque ninguém consegue estimar:

• Resgate de projeto: assumir código de outro time. Você não sabe o que vai encontrar até abrir o repositório, e às vezes nem depois.
• Manutenção e evolução contínua: demandas que chegam toda semana, sem backlog fechado. Aqui o formato natural é hora ou pacote mensal de horas.
• Descoberta e prototipagem: o próprio objetivo é descobrir o escopo. Precificar o desconhecido a preço fechado é apostar.
• Cliente que muda de ideia rápido, e sabe disso: startups em validação, por exemplo. Cobrar por hora deixa o custo da mudança visível e transfere a decisão para quem muda.

Para cobrar por hora sem virar refém do timesheet, três regras salvam a relação:

1. Estimativa por demanda antes de começar. "Essa feature deve levar de 8 a 12 horas." O cliente aprova a faixa, não descobre o total depois.
2. Teto mensal combinado. "Até 60 horas por mês; acima disso, alinhamos antes." Protege o caixa dele e a sua agenda.
3. Reporte semanal, não mensal. Surpresa de 40 horas no fim do mês gera briga. Resumo toda sexta com o que foi feito e quanto consumiu gera confiança.

O terceiro caminho: preço fechado por etapa

O modelo que a OCA mais usa em projeto novo não é nenhum dos dois puros. É preço fechado por etapa, com replanejamento entre elas:

1. Etapa 1, descoberta: valor fechado e pequeno (algo entre R$ 2 mil e R$ 6 mil, dependendo do porte) para levantar requisitos, desenhar fluxos e fechar o escopo da construção. O entregável é um documento que qualquer dev conseguiria orçar.
2. Etapa 2, construção do núcleo: preço fechado em cima do escopo que a etapa 1 produziu. Agora a estimativa tem base, não fé.
3. Etapa 3 em diante: evoluções em novos pacotes fechados ou em horas mensais, conforme o ritmo do cliente.

Esse formato resolve o paradoxo central do freelance: o cliente quer preço antes de definir o que quer, e você não consegue dar preço sem definição. A descoberta paga quebra o impasse. E tem um efeito colateral bom: cliente que se recusa a pagar uma descoberta pequena estava procurando orçamento grátis, não fornecedor. Melhor descobrir isso na primeira semana do que na décima.

A conta na prática: o mesmo projeto nos dois modelos

Suponha um sistema web de gestão que você estima em 160 horas, com sua hora de referência a R$ 120.

• Por hora: 160 × R$ 120 = R$ 19.200. Se estourar para 200 horas, o cliente paga R$ 24.000. Seu risco é reputacional, não financeiro.
• Preço fechado: a base é R$ 19.200, mas você adiciona margem de risco. Em escopo bem fechado, 20% já cobre imprevisto razoável: R$ 23.000. Em escopo médio, 30% a 40%. Se a margem necessária passa de 40%, o recado é outro: o escopo está vago demais para preço fechado, volte uma casa e proponha descoberta.

Repare que o preço fechado saudável é mais caro que a projeção por hora. Tem que ser. Previsibilidade é um produto e o cliente paga por ela. O erro clássico do freelancer é fazer o contrário: dar preço fechado abaixo da conta de horas para "ganhar o projeto". Isso não é competitividade, é doar sua margem de risco.

As cláusulas que fazem qualquer modelo funcionar

Independente do modelo, três combinados por escrito evitam a maior parte das brigas:

• Regra de mudança: alteração de escopo em preço fechado vira aditivo com valor e prazo próprios, sempre por escrito antes de codar. Sem isso, todo "ajustezinho" sai do seu bolso.
• Prazo de resposta do cliente: aprovação parada por mais de X dias úteis pausa o cronograma. Projeto fechado que dorme três semanas esperando um logo não pode contar como atraso seu.
• Rodadas de revisão limitadas: cada entrega tem, por exemplo, duas rodadas de ajustes inclusas. A terceira é cobrada. Isso transforma feedback infinito em feedback objetivo.

Isso não é teoria, é literalmente como a OCA opera. A gente aprendeu cada uma dessas cláusulas do jeito caro, absorvendo estouro que era evitável com um parágrafo de contrato.

E quando o projeto chega pronto para orçar?

Tudo que descrevi fica mais fácil quando o projeto chega até você já filtrado: com escopo desenhado, cliente educado sobre o processo e expectativa de preço alinhada. Esse é exatamente o formato dos projetos que a OCA repassa para a rede de parceiros. A visibilidade no Google e nas IAs traz mais leads do que o time consegue atender, então projetos passam por triagem, descoberta e definição de escopo antes de chegar ao parceiro. O dev entra para construir, não para adivinhar.

O que a OCA espera de um parceiro é o básico bem feito: entrega no combinado, comunicação em dia e código que outro senior consiga manter. O que o parceiro recebe é o que mais falta para quem trabalha sozinho: pipeline. Se você já entrega bem, o seu problema não é técnico, é distribuição.

Entre para a rede de parceiros da OCA

E uma ação para esta semana, independente de qualquer parceria: pegue seu último projeto de preço fechado, divida o valor pelas horas reais e compare com a hora que você acha que vale. Se o número te incomodar, você acabou de descobrir quanto custa não cobrar pelo risco. No próximo orçamento, escolha o modelo de forma consciente em vez de aceitar o que o cliente propôs.