Quanto cobrar como programador freelancer em 2026?
Aprenda a calcular seu valor-hora mínimo, transformar escopo em preço de projeto e incluir custos, impostos, risco, reuniões, suporte e margem sem chutar.
A pergunta parece simples:
quanto eu deveria cobrar por este projeto?
Mas quase nunca existe uma resposta correta em forma de tabela.
Um site pode custar R$ 2 mil ou R$ 20 mil.
Uma integração pode levar duas horas ou duas semanas.
Um sistema simples para um cliente pode virar uma operação crítica para outro.
E dois programadores com a mesma experiência podem precisar cobrar valores diferentes porque possuem:
- custos diferentes;
- regimes tributários diferentes;
- disponibilidade diferente;
- risco diferente;
- capacidade de entrega diferente;
- posicionamento diferente.
O erro mais comum é procurar primeiro:
“quanto os outros cobram?”
Essa informação pode servir como referência.
Mas ela não deveria ser o ponto de partida.
O ponto de partida é descobrir quanto você precisa cobrar para o trabalho ser sustentável.
Depois você compara esse piso com:
- mercado;
- valor entregue;
- urgência;
- complexidade;
- risco;
- posicionamento.
Neste guia, vamos construir essa conta.
A resposta curta
Se você quer uma fórmula prática, use esta:
valor-hora mínimo =
(meta mensal
+ custos do negócio
+ impostos provisionados
+ reservas)
÷ horas realmente faturáveis
Depois, para um projeto fechado:
preço-base do projeto =
horas estimadas
× valor-hora mínimo
E então ajuste por:
+ risco
+ urgência
+ complexidade
+ suporte
+ responsabilidade
+ margem
O resultado não é necessariamente o preço final.
É seu piso econômico.
Abaixo dele, você começa a financiar o projeto com o próprio tempo.
Por que dividir pelo mês inteiro dá errado
Imagine que você queira retirar R$ 8.000 por mês.
Você trabalha 160 horas.
Então:
R$ 8.000 ÷ 160 = R$ 50/h
Parece razoável.
Só que existe um problema.
Você não fatura 160 horas.
Parte do mês vai para:
- reuniões;
- propostas;
- prospecção;
- mensagens;
- financeiro;
- emissão de nota;
- estudo;
- manutenção do ambiente;
- suporte;
- retrabalho;
- períodos sem projeto.
Se você só consegue faturar 100 horas, por exemplo:
R$ 8.000 ÷ 100 = R$ 80/h
E ainda não incluímos custos, impostos ou reserva.
Essa diferença é enorme.
Horas trabalhadas não são horas faturáveis
Essa é provavelmente a variável mais ignorada.
Pense em uma semana de 40 horas.
Talvez ela contenha:
- 24 horas de execução cobrável;
- 4 horas de reunião;
- 3 horas de atendimento;
- 3 horas de proposta/prospecção;
- 2 horas de administrativo;
- 4 horas de aprendizado, organização e imprevistos.
Nesse exemplo:
40 horas trabalhadas
≠
40 horas faturáveis
Você faturou 24.
Seu negócio precisa pagar pelas outras 16 também.
Comece pela sua meta de retirada
Pergunte:
Quanto preciso receber por mês para este trabalho fazer sentido?
Não pense apenas em sobreviver.
Considere:
- despesas pessoais;
- padrão de vida;
- investimentos;
- descanso;
- férias;
- segurança.
Vamos usar um exemplo:
meta de retirada: R$ 8.000/mês
Esse ainda não é o faturamento necessário.
É apenas sua retirada desejada.
Adicione os custos do negócio
Mesmo trabalhando sozinho, você possui estrutura.
Pode incluir:
- internet;
- energia;
- computador;
- monitor;
- hospedagem;
- domínio;
- software;
- IA;
- GitHub;
- ferramentas;
- contabilidade;
- telefone;
- coworking;
- aquisição de clientes.
Imagine:
custos mensais do negócio: R$ 1.500
Agora temos:
R$ 8.000
+ R$ 1.500
= R$ 9.500
Provisione impostos
A carga tributária depende de fatores como:
- natureza da atividade;
- regime tributário;
- faturamento;
- pró-labore;
- fator R;
- município;
- forma de contratação.
Portanto, não existe uma porcentagem universal que eu possa colocar aqui e dizer “use isso”.
Use a sua realidade contábil.
Para o exemplo, vamos apenas supor uma provisão hipotética de 12%.
R$ 9.500 ÷ (1 - 0,12)
≈ R$ 10.795
Isso quer dizer que, para sobrar aproximadamente R$ 9.500 após essa provisão simplificada, seria necessário faturar cerca de R$ 10.795.
Não use esse 12% como orientação tributária.
Substitua pelo seu número real.
Férias também custam dinheiro
Quando você é funcionário, férias remuneradas fazem parte da remuneração.
Como freelancer, se parar de trabalhar e não houver receita recorrente, o faturamento pode parar junto.
Uma forma simples é criar provisão.
Por exemplo:
1 mês de descanso por ano
≈ 8,3% de provisão
Você também pode criar reservas para:
- equipamentos;
- períodos de baixa;
- doença;
- treinamento;
- emergência.
Vamos arredondar nosso custo mensal necessário para:
R$ 12.000/mês
Agora podemos calcular a hora.
Quantas horas você realmente vende?
Suponha que você consiga faturar:
100 horas/mês
Então:
R$ 12.000 ÷ 100
= R$ 120/h
Esse R$ 120 não é automaticamente seu preço comercial.
É seu valor-hora mínimo econômico neste exemplo.
Abaixo disso, você começa a sacrificar alguma coisa:
- retirada;
- reserva;
- margem;
- investimento;
- segurança.
Meu valor-hora não precisa aparecer na proposta
Isso é importante.
Você pode calcular internamente:
R$ 120/h
e vender:
Projeto completo: R$ 9.800.
O cliente não precisa comprar horas.
Você usa a hora como unidade interna de custo.
Essa distinção permite cobrar por projeto sem perder referência econômica.
Por hora ou por projeto?
Os dois modelos fazem sentido em contextos diferentes.
Cobrança por hora
Funciona bem quando:
- escopo é aberto;
- existe suporte contínuo;
- o cliente prioriza tarefas;
- trabalho é consultivo;
- não sabemos antecipadamente quanto será necessário.
Exemplos:
- manutenção;
- consultoria;
- troubleshooting;
- sustentação;
- pequenas evoluções contínuas.
Preço fechado por projeto
Funciona melhor quando:
- entregável é claro;
- critérios de aceite estão definidos;
- existe começo e fim;
- você consegue estimar.
Exemplos:
- landing page;
- site institucional;
- integração;
- plugin;
- MVP;
- migração.
O erro não é escolher hora ou projeto.
É cobrar projeto fechado com escopo aberto.
Como calcular preço por projeto
Imagine uma integração.
Você estima:
levantamento: 4 h
arquitetura: 4 h
implementação: 28 h
testes: 10 h
deploy: 4 h
reuniões: 5 h
documentação: 5 h
-------------------------
total: 60 h
Seu piso interno:
R$ 120/h
Preço-base:
60 × 120 = R$ 7.200
Agora começa a parte que muita gente esquece.
Estimativa não é certeza
Projetos de software têm incerteza.
Talvez a API externa tenha documentação ruim.
Talvez o sistema legado seja inconsistente.
Talvez o cliente mude regras.
Talvez exista dado que você ainda não viu.
Por isso, não trate a estimativa como verdade absoluta.
Uma abordagem possível:
estimativa técnica: R$ 7.200
contingência de risco: 15%
----------------------------
R$ 8.280
Esse percentual não é uma regra universal.
Quanto mais incerto o projeto, maior precisa ser sua proteção — ou mais você deveria reduzir o escopo antes de fechar.
O melhor desconto é reduzir escopo
Cliente:
“R$ 8.280 ficou caro. Consegue fazer por R$ 6.000?”
Uma resposta ruim:
“Consigo.”
Uma resposta melhor:
“Podemos ajustar o escopo.”
Por exemplo:
versão A
integração completa
dashboard
logs
retry
documentação
R$ 8.280
Versão reduzida:
versão B
integração principal
logs básicos
sem dashboard
sem automação de retry
R$ 6.100
Você reduz preço reduzindo obrigação.
Isso preserva margem e clareza.
Urgência tem custo
Imagine um projeto de duas semanas.
O cliente precisa em três dias.
Você talvez precise:
- remarcar outras entregas;
- trabalhar fora do horário;
- assumir mais risco;
- perder capacidade de atender outro cliente.
Então urgência não deveria custar igual.
Você não está cobrando “porque pode”.
Está precificando o custo de oportunidade da prioridade.
Complexidade não é quantidade de telas
Uma integração de uma tela pode ser mais complexa que um painel com vinte.
Complexidade pode vir de:
- legado;
- regras;
- dados;
- segurança;
- concorrência;
- pagamento;
- múltiplos sistemas;
- performance;
- permissões;
- compliance;
- indisponibilidade.
Não use apenas “quantas páginas”.
Pergunte:
quantas coisas precisam estar corretas ao mesmo tempo?
Responsabilidade também entra no preço
Um script interno que gera relatório não possui o mesmo risco que:
- checkout;
- sistema financeiro;
- prontuário;
- autenticação;
- folha de pagamento;
- produção industrial.
Mesmo que o número de horas seja parecido.
Quanto maior o impacto de erro, maior o trabalho necessário em:
- teste;
- segurança;
- validação;
- monitoramento;
- documentação;
- rollback.
Esse esforço precisa aparecer na proposta.
Suporte não deve ficar implícito
Um dos piores termos em proposta é:
“suporte incluso”.
Por quanto tempo?
Para quê?
Com qual SLA?
Inclui novas funcionalidades?
O cliente pode mandar mensagem domingo?
Defina.
Exemplo:
30 dias de garantia:
- correção de defeitos do escopo entregue;
- atendimento em horário comercial;
- não inclui nova funcionalidade;
- não inclui alteração de regra aprovada.
Depois:
manutenção mensal opcional:
R$ X/mês
Clareza reduz conflito.
Scope creep: o projeto que cresce sem o preço crescer
Começa assim:
“Só mais um campo.”
Depois:
“Já que estamos aqui…”
Depois:
“É pequeno.”
No final, você vendeu 60 horas e entregou 90.
Por isso uma proposta precisa definir:
- incluído;
- não incluído;
- número de revisões;
- dependências do cliente;
- critérios de aceite;
- processo para mudança.
A regra pode ser simples:
escopo novo = avaliação nova.
Sem drama.
E a IA? Se eu faço mais rápido devo cobrar menos?
Não necessariamente.
Suponha:
Antes:
20 horas
× R$ 120
= R$ 2.400
Com IA:
8 horas
Se você cobrar apenas horas:
8 × 120 = R$ 960
Você acabou de usar uma ferramenta para aumentar produtividade e entregou todo o ganho ao cliente.
Isso pode fazer sentido em alguns contratos por hora.
Mas em projeto fechado, o cliente está comprando um resultado.
Se você consegue entregar com:
- mesma qualidade;
- menor prazo;
- menor risco;
isso não torna o trabalho automaticamente menos valioso.
Velocidade adquirida por experiência e ferramentas é capacidade.
Não desconto obrigatório.
Mas não use IA para esconder baixa qualidade
Existe o outro extremo.
Você fecha por R$ 10 mil.
A IA gera tudo em algumas horas.
Você não revisa.
E entrega um sistema frágil.
Isso não é margem.
É transferência de risco para o cliente.
O ganho legítimo de produtividade existe quando:
menos tempo
+
mesma ou melhor qualidade
+
controle de risco
Quanto o mercado cobra em 2026?
Existem guias brasileiros publicados em 2026 mostrando faixas bastante amplas para desenvolvimento freelancer.
Alguns levantamentos secundários colocam taxas desde dezenas de reais por hora para iniciantes até algumas centenas por hora para profissionais mais experientes e especialidades como IA, pagamentos e arquitetura.
Essa amplitude é justamente o motivo pelo qual tabelas precisam ser tratadas como referência, não fórmula.
Duas pessoas podem cobrar R$ 100 e R$ 250 pela “mesma stack” e ambas estarem economicamente corretas.
O que muda?
- experiência;
- escopo;
- cliente;
- risco;
- especialização;
- velocidade;
- reputação;
- disponibilidade.
Use benchmark para verificar se sua conta está completamente fora da realidade.
Não para substituir sua conta.
Senioridade sozinha não define preço
Um sênior genérico pode valer menos para determinado projeto que um pleno especializado exatamente naquele problema.
Por exemplo:
- especialista em WooCommerce;
- integração com ERP específico;
- pagamentos;
- performance;
- segurança;
- IA aplicada;
- migração crítica.
Quanto mais específico o problema e mais custoso o erro, maior pode ser o valor da experiência relevante.
Preço também comunica posicionamento
Imagine duas propostas.
Proposta A
Site: R$ 3.000.
Proposta B
Objetivo: gerar pedidos de orçamento.
Inclui:
- arquitetura de páginas;
- implementação responsiva;
- integração de formulário;
- analytics;
- SEO técnico básico;
- publicação;
- 30 dias de garantia.
Investimento: R$ 6.800.
Mesmo antes de discutir valor, a segunda transmite outra coisa:
entendimento do problema.
Preço não existe isolado da oferta.
Não dê preço antes de entender o problema
Cliente:
“Quanto custa um sistema?”
Resposta correta:
“Depende.”
Mas não pare aí.
Pergunte:
- quem usa?
- qual problema resolve?
- o que acontece hoje?
- qual fluxo?
- quais integrações?
- quais dados?
- qual prazo?
- qual risco?
- quem aprova?
- o que define sucesso?
Precificação vem depois do diagnóstico.
Um checklist antes de enviar preço
Antes da proposta, verifique:
Financeiro
- Qual meu valor-hora mínimo?
- Incluí custos?
- Impostos?
- Reserva?
- Margem?
Escopo
- O que está incluído?
- O que não está?
- Existem critérios de aceite?
- Quantas revisões?
Risco
- Existem integrações desconhecidas?
- Legado?
- Dados?
- Segurança?
- Dependência de terceiro?
Operação
- Quem fornece acessos?
- Quem homologa?
- Quem publica?
- Existe suporte depois?
Comercial
- Forma de pagamento?
- Entrada?
- Marcos?
- Validade da proposta?
- Mudança de escopo?
Se você não consegue responder essas perguntas, o preço ainda é um chute.
Exemplo completo
Vamos juntar tudo.
Meta pessoal:
R$ 8.000
Custos:
R$ 1.500
Impostos + reservas + margem operacional:
R$ 2.500
Necessidade mensal:
R$ 12.000
Horas faturáveis:
100 h
Piso:
R$ 120/h
Projeto:
55 horas estimadas
× R$ 120
= R$ 6.600
Contingência:
15%
= R$ 990
Subtotal:
R$ 7.590
Suporte pós-entrega específico:
R$ 600
Faixa proposta:
aprox. R$ 8.200
Agora você possui lógica.
Pode decidir vender:
R$ 8.200
ou:
R$ 8.500
ou criar dois pacotes.
Mas não escolheu o número no ar.
Use uma faixa antes de travar o preço
Em projetos com descoberta incompleta, pode ser melhor dizer:
“Pelo que sabemos hoje, o projeto está na faixa de R$ 8 mil a R$ 11 mil. Fechamos o preço depois da etapa de diagnóstico.”
Isso evita fingir certeza.
Uma alternativa é cobrar pela descoberta.
Por exemplo:
diagnóstico técnico:
R$ 1.500
resultado:
- escopo;
- arquitetura;
- riscos;
- estimativa;
- roadmap.
Depois o cliente decide se contrata a implementação.
Entrada protege os dois lados
Em projeto fechado, começar sem entrada significa financiar o cliente.
Modelos comuns incluem:
50% início
50% entrega
ou:
30% início
40% marco intermediário
30% entrega
O desenho depende do projeto.
A ideia é alinhar fluxo de caixa com progresso e reduzir risco de inadimplência.
Nunca venda só código
O cliente raramente acorda pensando:
“Preciso de 80 horas de PHP.”
Ele quer:
- vender;
- automatizar;
- integrar;
- reduzir erro;
- atender melhor;
- publicar um produto.
Código é meio.
Quanto mais sua proposta conecta trabalho técnico ao resultado, menos a conversa fica presa em “quanto custa a hora?”.
Uma ferramenta para fazer a conta com seus números
No meu site existe a ferramenta Preço de Projeto, que usa pró-labore, custos, impostos, risco e horas para chegar a uma faixa defensável, incluindo:
- valor-hora mínimo;
- piso de negociação;
- checklist de proposta.
Você pode usar gratuitamente na área de ferramentas de precificação.
A ferramenta não decide seu preço.
Ela evita que você comece pelo chute.
Próximo nível
Calcular o preço resolve uma parte do problema.
Ainda falta transformar habilidade em uma oferta que o cliente consiga entender e comprar.
No curso Oferta, eu aprofundo esse próximo passo: problema, cliente, escopo, posicionamento, precificação e empacotamento para quem já sabe entregar mas ainda trava na hora de colocar no papel o que vende e por quanto.
A lógica é simples:
habilidade
↓
problema
↓
oferta
↓
escopo
↓
preço
↓
proposta
↓
cliente
Cobrar bem não é descobrir um número mágico.
É construir um preço que:
- paga sua operação;
- protege seu tempo;
- corresponde ao risco;
- faz sentido para o cliente;
- e permite continuar entregando bem depois que o contrato foi assinado.