Preço fechado ou por hora no freelance dev: qual modelo de cobrança usar em cada projeto (e o híbrido que a OCA usa)
Lucas Annunziato · · 9 min de leitura
Chega o pedido no WhatsApp: “quanto fica para fazer um sistema de agendamento?”. Não tem escopo fechado. O cliente ainda não sabe direito o que quer, mas quer um número. Você chuta R$ 25 mil, preço fechado, porque foi isso que ele pediu e porque cobrar por hora parece que assusta. Três meses depois, o projeto já consumiu o dobro das horas. Toda semana o cliente pede “só mais uma telinha”, e você está trabalhando por menos do que ganhava no último emprego CLT.
Quase nunca o problema foi o valor. Foi o modelo de cobrança. Preço fechado, hora, banco de horas e sprint não são só jeitos diferentes de emitir a fatura. Cada um decide quem paga a conta quando a estimativa erra. E a estimativa sempre erra.
Preço fechado ou por hora: o que o modelo de cobrança decide de verdade
A verdade desconfortável é esta: todo projeto de software tem incerteza, e alguém vai pagar por ela. No preço fechado, quem paga é você. No preço por hora, quem paga é o cliente. Nenhum modelo é neutro.
A maioria dos devs escolhe o modelo por hábito ou porque o cliente pediu. O cliente leigo quer preço fechado porque precisa saber quanto vai gastar. O dev aceita porque tem medo de perder o projeto. O resultado é o pior arranjo possível: o lado que menos entende de software define o escopo, e o lado que entende assume todo o risco.
Vou te falar como funciona do lado de quem recebe os leads: chegam dezenas de pedidos de orçamento por dia na OCA, e quase todos pedem “um valor fechado”. Isso é legítimo. Quem vai investir R$ 40 mil precisa planejar o caixa. O que a gente aprendeu foi dar previsibilidade ao cliente sem assinar um cheque em branco de horas.
Os 4 modelos de cobrança no freelance dev e quando usar cada um
| Modelo | Quem carrega o risco | Funciona bem quando | Evite quando |
|---|---|---|---|
| Preço fechado | Você | O escopo é pequeno, claro e você já fez algo igual (landing page, integração conhecida, app simples com telas definidas) | O cliente ainda está descobrindo o produto |
| Por hora (time and material) | Cliente | Código legado desconhecido, resgate de projeto, cliente técnico que quer controlar a prioridade | O cliente é leigo e não tem orçamento definido |
| Banco de horas mensal | Dividido | Evolução contínua de produto já em produção, suporte, melhorias | É um projeto novo com data de lançamento |
| Sprint ou pacote por período | Dividido | MVP em construção, produto que muda toda semana, cliente que quer ver avanço frequente | O cliente exige lista fechada de funcionalidades |
Faixas de referência em 2026
- Hora de dev pleno ou sênior atendendo direto o cliente: de R$ 120 a R$ 250, dependendo da stack, do nicho e de você assumir também design e infraestrutura.
- Banco de horas: pacotes de 20 a 60 horas por mês, normalmente com 10% a 15% de desconto sobre a hora avulsa em troca da previsibilidade. Exemplo: 40 horas a R$ 150 dão R$ 6.000 por mês.
- Sprint de duas semanas: entre R$ 8 mil e R$ 18 mil para um dev sênior, conforme a dedicação (meio período ou integral) e a complexidade da stack.
O que mexe nesses números: experiência comprovada no nicho do cliente, urgência, se você responde pela produção (plantão, incidentes) e quanto do projeto depende de terceiros, como gateway de pagamento ou API de governo.
A conta do preço fechado: quanto de margem de risco colocar
Se você vai cobrar preço fechado, a margem de risco não é ganância. É o preço do risco que você assume no lugar do cliente. A conta é simples.
Imagine um projeto estimado em 200 horas, com a sua hora a R$ 150. Sem margem, o preço fica em R$ 30 mil. Com 30% de margem de risco, R$ 39 mil. Veja o que acontece com a sua hora real em três cenários:
| Cenário | Horas reais | Hora real sem margem (R$ 30 mil) | Hora real com 30% de margem (R$ 39 mil) |
|---|---|---|---|
| A estimativa acertou | 200 | R$ 150 | R$ 195 |
| Estourou 25% | 250 | R$ 120 | R$ 156 |
| Estourou 50% | 300 | R$ 100 | R$ 130 |
Com 50% de estouro, que não é raro em projeto com integração externa, quem não colocou margem está trabalhando por R$ 100 a hora. E isso antes de descontar imposto, ferramentas e o mês parado entre um projeto e outro.
A regra que a gente usa: de 15% a 20% de margem quando o escopo é conhecido e você já entregou algo igual. De 25% a 40% quando há integração com terceiro, código legado ou um cliente que nunca teve software. Se a margem necessária passa de 40%, o projeto não deveria ser de preço fechado. Ele deveria começar com um discovery pago ou ir para hora ou sprint.
E o cliente aceita pagar a margem? Muitas vezes, sim, porque está comprando previsibilidade. Quem não aceita costuma também não aceitar o aditivo quando o escopo crescer.
O modelo híbrido que a OCA usa (e por que funciona para os dois lados)
Isso não é teoria, é literalmente como a OCA cobra hoje. Nenhum produto que a gente opera em produção ficou pronto no escopo do primeiro dia, e isso inclui o Revo, com mais de 40 mil usuários e mais de 300 eventos por mês. O checkout que hoje converte 90% é resultado de iteração com usuário real, não de uma especificação fechada antes da primeira linha de código. Por isso a gente divide o projeto em três fases, cada uma com o modelo que combina com o risco dela:
- Discovery com preço fechado. Uma a duas semanas, de R$ 3 mil a R$ 8 mil, com entregável claro: escopo, fluxos, estimativa por funcionalidade e riscos mapeados. O risco aqui é pequeno, então o preço fechado faz sentido.
- Construção por marcos, com preço fechado por fase. Em vez de um número para o projeto inteiro, cada marco tem escopo e valor próprios. Se o marco 2 revelar algo que ninguém previu, você reprecifica o marco 3 em vez de engolir a diferença.
- Evolução por banco de horas. Depois do lançamento, melhorias e ajustes entram em um pacote mensal. O cliente decide a prioridade, e você garante a capacidade.
O cliente ganha previsibilidade, porque sabe o valor de cada fase antes de aprovar. Você ganha proteção, porque o erro de estimativa fica limitado a um marco, e não ao projeto inteiro. E o banco de horas transforma o fim do projeto no começo da relação.
Os erros de cobrança que mais queimam dev freelancer
Preço fechado com escopo aberto
O contrato diz “sistema de gestão para clínica”. Não tem lista de telas, lista de integrações nem critério de aceite. Qualquer coisa que o cliente imaginar cabe nessa frase, e você já recebeu o sinal. Preço fechado sem escopo escrito não é preço fechado. É hora ilimitada com teto de pagamento.
Hora sem teto que vira preço fechado sem margem
Você propõe cobrar por hora. O cliente fica inseguro e pede “uma estimativa máxima”. Para não perder o projeto, você fala em 150 horas. Pronto: na cabeça do cliente, o teto virou preço fechado, só que sem nenhuma margem de risco. Se for dar teto, dê uma faixa (de 150 a 200 horas) e deixe escrita a regra do que acontece quando o projeto chegar a 80% dela.
Banco de horas sem validade
O cliente compra 40 horas por mês. Usa 10 em março, 5 em abril, e em junho aparece querendo 105 horas acumuladas para uma entrega urgente. Banco de horas precisa de regra: as horas não usadas expiram no mês ou acumulam por no máximo um mês. Sem isso, você vendeu capacidade e não consegue planejar a agenda.
Trocar de modelo no meio sem aditivo
O projeto começou com preço fechado, estourou, e você combinou por áudio que “daqui pra frente fica por hora”. Dois meses depois, o cliente só lembra da parte do preço fechado. Toda mudança de modelo vai por escrito, em aditivo assinado, com data de corte e o que já foi entregue até ali.
Cobrar por hora e entregar rápido demais
Com IA no fluxo, uma tarefa de 8 horas pode sair em 3. Se você só cobra por hora, o ganho de produtividade vai inteiro para o cliente. Em entregas repetíveis, como uma integração que você já fez cinco vezes, o preço fechado por entrega costuma pagar melhor que a hora.
Rede de parceiros da OCA: como funciona e o próximo passo
Se você já entrega bem, o seu problema não é técnico, é distribuição. A OCA aparece no Google e nas IAs quando alguém busca desenvolvimento de software no Brasil, e isso traz mais leads por dia do que o time consegue atender. Por isso a gente está montando uma rede de devs e pequenos times parceiros para receber projetos repassados.
Como isso se conecta com este artigo: quando a OCA repassa um projeto, ele chega qualificado e com escopo desenhado, e a forma de cobrança já foi pensada para não deixar o risco inteiro no colo de ninguém. Em troca, a gente espera algumas coisas dos parceiros:
- Estimativa honesta, com a margem de risco explícita, e não escondida.
- Registro real das horas quando o projeto é por hora ou banco de horas.
- Aviso de estouro antes que ele aconteça, e não depois.
- Código e acessos entregues de um jeito que outro dev consiga continuar.
O parceiro recebe projeto já vendido, sem precisar prospectar, e trabalha com o mesmo modelo de cobrança que a OCA usa nos próprios produtos. Não existe garantia de volume nem de aceite: cada dev passa por uma conversa e por uma avaliação dos trabalhos anteriores. Para ver o tipo de produto que a gente constrói, confira os projetos da OCA em produção.
Entre para a rede de parceiros da OCA
E uma coisa para fazer esta semana, entrando na rede ou não: pegue os seus três últimos projetos e divida o valor recebido pelas horas que você realmente trabalhou. Compare com a hora que você acha que cobra. Se a diferença passar de 20% em mais de um deles, o problema não é o seu preço. É o modelo de cobrança, e o próximo orçamento já pode sair no formato híbrido.
