CalcFreela › Calculadora de preço por hora › Desenvolvedor
Calcule seu piso por hora e converta em diária, semana ou sprint — que é como o mercado de dev realmente fecha contrato.
Quase nenhum contrato sério de desenvolvimento é fechado em "R$ X por hora, me manda o cartão de ponto". O mercado de dev negocia em diária, em alocação mensal (o famoso body-shop) ou em projeto fechado com escopo definido. Mesmo assim, calcular o preço por hora continua sendo o primeiro passo — é a unidade que você usa internamente para comparar propostas, decidir se vale trocar de cliente e saber se aquele sprint de "preço fechado" te deu prejuízo.
A calculadora abaixo monta o seu piso por hora a partir dos seus custos reais — inclusive os que só quem programa paga, como cloud de ambiente de teste, licença de IDE e certificação. Depois, o módulo de conversão logo abaixo transforma esse piso em diária, semana e sprint, que é a unidade que aparece de fato nas propostas e nos contratos de alocação.
Body-shop cobra por mês de alocação, projeto cobra fechado, mas quase todo contrato de dev nasce de uma referência de diária. Converta aqui sem dar desconto sem perceber.
Antes de preencher o campo "custos do negócio" da calculadora acima, passe por esta lista. Programador costuma subestimar o próprio custo fixo porque boa parte dele é "só uma assinatura de US$ 10" — que, somada, vira uma conta grande no fim do mês:
O erro mais comum de quem começa a fazer freelas de desenvolvimento é tratar todo contrato como se fosse a mesma coisa com preços diferentes. Não é. São três modelos de negócio distintos, com risco e margem diferentes, e a calculadora acima ajuda a comparar os três porque todos partem do mesmo piso por hora.
Body-shop (alocação por mês) é você vender tempo dedicado: um número de horas por mês, geralmente dentro do time do cliente, seguindo o ritmo e as ferramentas dele. O risco de estimativa errada é baixo — você não promete entregar uma feature específica, promete estar disponível — mas a margem também costuma ser menor, porque o cliente está pagando por previsibilidade, não por risco assumido por você.
Projeto fechado é o oposto: você promete um resultado por um valor fixo, e todo o risco de a estimativa estourar é seu. Isso justifica um preço/hora efetivo mais alto — o buffer da seção seguinte existe exatamente para isso. Diária avulsa fica no meio: você vende um dia de trabalho definido, sem o compromisso de mês inteiro do body-shop nem o risco total do projeto fechado. É o formato que a conversão desta página usa como referência, porque é a unidade mais fácil de negociar com quem nunca contratou dev freelancer antes.
Estimativa de software erra para cima quase sempre, e não é falta de experiência: é a natureza do trabalho. Você não sabe o tamanho real de um problema até abrir o código, e código alheio (ou até o seu, de seis meses atrás) sempre esconde uma dependência, uma regra de negócio não documentada ou uma integração que não funciona como a documentação promete. Prometer um número exato de horas antes de investigar é, na prática, um chute otimista.
A defesa contra isso não é "estimar melhor" — é embutir um buffer explícito na conta e ser honesto sobre o que ele cobre. Um projeto estimado em 40 horas de execução limpa raramente fecha em 40 horas reais; imprevistos de ambiente, dependência desatualizada e reunião extra de alinhamento comem uma fatia previsível do tempo. Colocar esse buffer como uma porcentagem visível na proposta (não escondido dentro de um preço "redondo") também facilita a conversa se o projeto realmente estourar: você já tinha avisado que aquela era a margem de segurança, não a garantia.
O outro lado da moeda é separar escopo fechado de escopo aberto na proposta. Escopo fechado é uma lista específica de entregas com critério de "pronto" claro — e para ele cabe preço fixo com buffer. Escopo aberto ("vamos evoluindo o sistema conforme a necessidade") não deveria nunca ter preço fixo: ou vira contrato de alocação mensal (horas por mês, sem prometer entrega X), ou vira uma sequência de mini-projetos fechados, cada um orçado na hora. Misturar os dois — prometer preço fixo para escopo que ainda não está definido — é a causa mais comum de dev trabalhando de graça nos últimos dias do projeto.
Entregar o projeto não é o fim do trabalho, mas muita gente cobra como se fosse. Depois do deploy, sempre aparece alguma correção — um bug que só se manifesta em produção, um ajuste que o cliente pediu e esqueceu de incluir no escopo, uma dependência que precisa de atualização de segurança. Se isso não está escrito em algum lugar, vira "suporte" gratuito por tempo indeterminado.
O jeito mais simples de resolver é separar dois itens já na proposta original: um período de garantia curto e explícito (por exemplo, correção de bugs relacionados ao escopo entregue, por um número definido de dias após a entrega) e um plano de manutenção à parte, cobrado como pacote mensal de horas ou como valor por chamado, para tudo que vem depois disso — atualização, evolução, suporte a incidente. Sem essa linha separada, o cliente naturalmente assume que "manutenção" está incluída no preço do projeto para sempre, porque ninguém combinou o contrário.
Vale também documentar o que conta como "bug do projeto entregue" e o que conta como "pedido novo". Um botão que não funciona como especificado é bug. Um botão que o cliente decidiu, depois de ver o sistema pronto, que deveria fazer outra coisa é mudança de escopo — e mudança de escopo tem preço, mesmo que pareça pequena.
Existe um custo real em desenvolvimento que raramente entra em planilha nenhuma: o tempo que você gasta recarregando na cabeça o estado de um projeto depois de ficar um tempo longe dele. Reabrir um repositório que você não toca há duas semanas, lembrar por que uma decisão de arquitetura foi tomada daquele jeito, reler a própria documentação — isso consome horas que não produzem nenhuma linha de código nova, só reconstroem o entendimento que você já tinha.
Quem atende vários clientes pequenos ao mesmo tempo, alternando entre projetos no mesmo dia, paga esse custo várias vezes por semana sem perceber. É uma das razões pelas quais um contrato de alocação contínua (um cliente, várias horas seguidas, todo dia) costuma ser mais produtivo por hora do que a mesma quantidade de horas espalhada entre cinco projetos diferentes — mesmo que o preço/hora cobrado seja igual nos dois casos.
Na prática, isso justifica dois ajustes na precificação: cobrar um pouco mais por projetos pequenos e esporádicos (porque o custo de contexto por hora entregue é maior neles) e, quando possível, negociar blocos de tempo contínuo em vez de "vou encaixando ao longo da semana". Não é um número que a calculadora calcula sozinha — é uma decisão que você toma ao revisar a sua agenda e perceber onde o tempo está realmente indo.
Dev freelancer costuma ter contrato de alocação com um cliente, projeto fechado com outro e um chamado de manutenção pendurado com um terceiro. O Freelance Ledger é um CRM grátis no Notion pra organizar isso sem precisar de planilha nova a cada projeto.
Grátis, é só duplicar no seu Notion. Existe uma versão paga com o módulo financeiro (US$29) — a grátis funciona sozinha, sem prazo.
Não existe tabela de mercado confiável para copiar — o valor certo é o que cobre os seus custos de vida e de negócio, dividido pelas suas horas realmente faturáveis, com margem e impostos embutidos. É essa conta que a calculadora desta página faz. O resultado é o seu piso, e o valor que você efetivamente cobra em diária ou projeto costuma ficar acima dele.
Depende do tipo de trabalho. Alocação contínua (body-shop) costuma ser vendida por mês ou por diária dentro de um contrato mensal. Trabalho pontual com escopo claro é melhor vendido como projeto fechado, com o preço calculado a partir da hora, mas apresentado como valor único. Cobrar hora avulsa direto do cliente final é raro no mercado e tende a gerar desconfiança sobre o tamanho da fatura.
Depende do que foi combinado na proposta. Se o buffer para imprevistos estava explícito e o estouro está dentro dele, é seu risco mesmo. Se o estouro vem de pedido novo do cliente ou de escopo que não estava descrito, é mudança de escopo e deve ser orçada à parte — o ideal é ter essa regra escrita antes de começar o projeto, não negociada no meio dele.
Não existe um número universal — depende do tamanho do sistema e da frequência de chamados esperada. Duas formas comuns são um pacote de horas mensal (você define um teto de horas incluídas) ou um valor por chamado avulso. O importante é que seja um item separado do preço do projeto, combinado antes da entrega, não uma suposição do cliente.
Vale considerar isso na proposta, não no meio do projeto. Se o histórico com aquele tipo de cliente mostra retrabalho alto, aumentar o buffer de imprevistos ou reduzir o número de revisões incluídas é mais saudável do que simplesmente inflar o preço/hora sem explicação — fica mais fácil de justificar e de negociar.
Depende do seu volume de faturamento e do tipo de contrato que os seus clientes exigem — isso é uma decisão fiscal, não técnica. Consulte um contador para entender qual enquadramento faz sentido no seu caso; o custo da contabilidade, de qualquer forma, deve entrar na conta de custos do negócio, como mostra o checklist acima.
Não. Toda a conta roda no seu navegador. Nada do que você digita é enviado para servidor nenhum nem armazenado. É grátis e não pede cadastro.
Este conteúdo é informativo e não substitui orientação contábil ou jurídica. Regras de tributação, enquadramento PJ e contratos internacionais variam conforme o seu caso — consulte um contador ou advogado.
Cole este código e ofereça a ferramenta aos seus leitores — grátis, sempre atualizada, sem cadastro pra eles.