Precificar software começa pelo custo real da hora faturável da equipe, que é o piso. Sobre ele, escolha o modelo pelo nível de incerteza: hora para escopo aberto, escopo fechado com contingência para requisitos estáveis e valor quando o resultado para o cliente é mensurável.
Precificar um projeto de software começa por calcular o custo real de uma hora faturável da equipe, que é o piso abaixo do qual a empresa perde dinheiro. Sobre esse piso, o modelo de cobrança deve seguir o nível de incerteza: cobrança por hora quando o escopo ainda vai mudar, escopo fechado com contingência quando os requisitos são estáveis e preço por valor quando o resultado para o cliente é mensurável e a software house domina o problema.
Qual é o piso: quanto custa uma hora da sua equipe?
O erro mais comum em software houses pequenas e médias é dividir o salário do desenvolvedor pelas horas do mês e chamar isso de custo. A conta real inclui tudo o que a empresa paga para manter a operação e divide pelas horas que efetivamente viram faturamento.
Uma forma simples de chegar ao custo da hora faturável:
- Some o custo mensal total da operação. Remuneração, encargos e benefícios da equipe técnica; gestão, comercial e administrativo; ferramentas, licenças e infraestrutura; aluguel, contabilidade e impostos que não variam com a receita.
- Calcule as horas disponíveis. Horas contratadas da equipe produtiva, descontando férias, feriados e ausências previsíveis.
- Aplique a taxa de utilização. Nem toda hora disponível é faturável. Reuniões internas, pré-venda, treinamento e tempo entre projetos consomem parte dela. Use o seu histórico, não uma meta otimista.
- Divida o custo total pelas horas faturáveis. O resultado é o custo de uma hora vendida.
- Some a margem desejada e os impostos sobre a receita. Só então você tem um preço mínimo por hora.
O custo da hora muda com o regime tributário, com o perfil da equipe e com a taxa de utilização. Por isso, revise a conta pelo menos a cada semestre. Um contador ajuda a acertar a parte tributária.
Como os três modelos de cobrança se comparam?
Os modelos não são melhores ou piores em absoluto. Cada um distribui o risco de forma diferente entre a software house e o cliente.
| Modelo | Como se cobra | Quem assume o risco de estimativa | Quando usar | Armadilha comum |
|---|---|---|---|---|
| Por hora (time and materials) | Horas trabalhadas por perfil | Cliente | Escopo aberto, MVP, integrações pouco documentadas | Cliente questionar horas sem entrega visível |
| Escopo fechado | Valor total por um escopo definido | Software house | Requisitos estáveis e especificação aprovada | Subestimar e absorver o prejuízo |
| Squad ou mensalidade | Equipe dedicada por mês | Cliente | Produto em evolução contínua | Equipe ociosa por falta de prioridade do cliente |
| Valor | Preço ligado ao resultado gerado | Compartilhado | Problema conhecido e resultado mensurável | Disputa sobre como medir o resultado |
As diferenças contratuais entre esses formatos são detalhadas em escopo fechado, time and materials ou squad dedicado. Do lado do comprador, os fatores que mais pesam no preço estão em quanto custa desenvolver um sistema sob medida.
Como precificar escopo fechado sem perder margem?
O escopo fechado transfere o risco de estimativa para a software house. Isso só é saudável quando o preço reflete esse risco.
- Decomponha o escopo. Estime funcionalidades pequenas, não o sistema inteiro. Quanto menor a unidade, menor o erro.
- Estime em faixas. Para cada item, registre um valor otimista, um provável e um pessimista. Uma média ponderada, como a da técnica PERT (otimista + 4 × provável + pessimista, dividido por 6), reduz o efeito do otimismo.
- Separe o que é conhecido do que é descoberta. Integrações com sistemas de terceiros, migração de dados e regras de negócio não documentadas costumam concentrar os desvios.
- Inclua contingência explícita. Uma reserva proporcional à incerteza, e não um percentual fixo para qualquer projeto.
- Liste as premissas na proposta. O que está fora, quem fornece acessos, quantas rodadas de revisão estão incluídas.
- Defina o processo de mudança. Toda alteração depois da assinatura passa por estimativa e aprovação antes de ser feita.
- Cobre a descoberta. Uma fase inicial curta, paga, que produz a especificação, reduz o risco de fechar um preço no escuro.
Quando cobrar por valor faz sentido?
Precificar por valor significa partir do impacto do projeto para o cliente, e não das horas necessárias para entregá-lo. Funciona melhor quando três condições existem ao mesmo tempo.
A primeira é que o problema seja conhecido pela software house, de preferência resolvido antes em empresas parecidas. A segunda é que o resultado possa ser medido com dados que o cliente já tem, como horas de trabalho manual eliminadas ou pedidos processados. A terceira é que o comprador decida por resultado, não por comparação de taxa horária.
Na prática, o preço por valor costuma aparecer como um valor fixo maior do que a soma das horas, justificado pelo resultado, ou como uma parte fixa somada a uma parte variável ligada a um indicador combinado. A especialização em um setor facilita esse modelo, como discutido em especializar a software house por vertical.
Como a IA no desenvolvimento muda a conta?
Ferramentas de IA podem mudar a quantidade de horas necessárias para entregar a mesma funcionalidade, e isso afeta diretamente a cobrança por hora. Se a equipe entrega mais rápido e o contrato paga por hora, a receita cai junto com o esforço.
Os estudos, porém, não apontam um número único. Em experimento controlado com o GitHub Copilot, desenvolvedores com acesso à ferramenta concluíram uma tarefa específica 55,8% mais rápido que o grupo de controle. Já um estudo randomizado da METR, com 16 desenvolvedores experientes trabalhando em repositórios que conheciam bem, encontrou o efeito contrário no início de 2025: com IA, as tarefas levaram 19% mais tempo, embora os próprios desenvolvedores acreditassem ter ficado cerca de 20% mais rápidos.
No nível da equipe, o relatório DORA de 2024, do Google Cloud, associou um aumento de 25% na adoção de IA a uma queda estimada de 1,5% na vazão de entrega e de 7,2% na estabilidade, ao lado de ganhos em documentação e revisão de código. Ganho individual não se converte automaticamente em entrega mais rápida.
A lição para precificação é medir antes de mudar o preço. Compare o tempo real de entrega de tarefas parecidas com e sem as ferramentas, nos seus projetos. O panorama completo está em IA no desenvolvimento de software: o que dizem os estudos.
Que sinais mostram que o preço está errado?
Alguns sintomas aparecem antes do prejuízo no fechamento do mês:
- Taxa de conversão muito alta. Ganhar quase todas as propostas pode indicar preço abaixo do mercado.
- Projetos de escopo fechado que estouram horas com frequência.
- Margem que cai à medida que o projeto avança, e não só no fim.
- Clientes que pedem desconto em toda proposta, sinal de que o valor não está claro.
- Equipe sem tempo para pré-venda, documentação ou treinamento.
Como apresentar o preço para o comprador?
O preço é lido junto com o resto da proposta, e muitas vezes por pessoas que não participaram das reuniões. Segundo dados do Gartner citados pela destinationCRM, compradores B2B dedicam apenas 17% da jornada a reuniões com fornecedores potenciais, e cada fornecedor comparado recebe entre 5% e 6% desse tempo. A proposta precisa se explicar sozinha.
Apresente o valor ligado a entregas e marcos, deixe explícitas as premissas e, quando fizer sentido, ofereça duas ou três opções de escopo. As técnicas estão em como escrever uma proposta de software que ganha concorrência.
Próximo passo
Preço defensável depende de prova. Cases com resultado e avaliações de clientes reais ajudam o comprador a aceitar um valor acima da comparação por hora. Publique esses dados onde ele pesquisa: crie ou reivindique o perfil gratuito da sua software house na Citeo ou conheça a área para empresas.
Fontes
- arXiv — The Impact of AI on Developer Productivity: Evidence from GitHub Copilot — experimento controlado em que o grupo com Copilot concluiu a tarefa 55,8% mais rápido
- METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — 16 desenvolvedores experientes, tarefas 19% mais longas com IA, percepção de ganho de cerca de 20%
- destinationCRM — Buyer Enablement Is the Key to B2B Sales — dados do Gartner sobre tempo em reuniões com fornecedores (17%) e tempo por fornecedor (5% a 6%)
- Google Cloud — Announcing the 2024 DORA report — efeitos da adoção de IA sobre vazão e estabilidade de entrega, citados como contexto para medir antes de reprecificar
Compare nota, avaliações verificadas e score, e fale direto com a empresa pela Citeo.
Perguntas frequentes
Como calcular o valor da hora de uma software house?
Some o custo mensal total da operação, inclusive gestão, comercial, ferramentas e impostos fixos, e divida pelas horas que efetivamente viram faturamento. Depois acrescente a margem e os impostos sobre a receita. Dividir apenas o salário pelas horas do mês subestima o custo.
É melhor cobrar por hora ou por projeto?
Depende da incerteza do escopo. Cobrança por hora protege a software house quando os requisitos vão mudar; escopo fechado dá previsibilidade ao cliente quando os requisitos estão estáveis. Muitas empresas combinam os dois, com uma descoberta a preço fixo seguida de desenvolvimento por fases.
Quanto de contingência colocar em um escopo fechado?
Não existe percentual universal. A contingência deve ser proporcional à incerteza de cada item, maior em integrações, migrações e regras pouco documentadas. Estimar em faixas e registrar premissas ajuda a dimensioná-la com base no seu histórico.
A IA deve baixar o preço dos projetos de software?
Não necessariamente. Os estudos mostram resultados divergentes, de ganhos expressivos em tarefas controladas a perdas em tarefas complexas com desenvolvedores experientes. Antes de mudar preços, meça o efeito nos seus projetos e considere modelos ligados a entregas ou valor, que não penalizam a eficiência.
Como justificar um preço maior que o dos concorrentes?
Mostre o que reduz o risco do comprador: cases parecidos com o problema dele, premissas claras, plano de entrega e avaliações verificáveis de clientes. Preço maior com risco menor costuma ser aceito; preço maior sem explicação, não.