Preço fechado ou por hora: como escolher o contrato
Preço fechado funciona quando o que você pediu já está decidido e pouca coisa vai mudar. Por hora funciona quando parte do pedido ainda precisa ser descoberta. O contrato define quem carrega a incerteza: no preço fechado é o fornecedor, que a embute no valor. Por hora, é você, que paga o que a descoberta custar.
Preço fechado ou por hora: qual contrato escolher?
Escolha pelo grau de decisão do pedido. Se você consegue dizer o que entra, o que sai, quem usa e quais sistemas e planilhas o novo sistema encosta, e quase nada disso vai mudar, o preço fechado é coerente. Se parte do pedido depende de descobrir como a operação funciona de fato, por exemplo uma regra de preço que só existe na cabeça de uma pessoa, o formato por hora, de preferência com teto, é mais coerente com o que se sabe.
Existe um teste simples. Pergunte: se eu mudar de ideia na sexta semana, quem paga? No preço fechado, a mudança vira aditivo e negociação. Por hora, ela vira horas na fatura do mês. Nenhum dos dois formatos elimina a mudança. Cada um decide quem a absorve.
O que a pesquisa diz sobre contratos de desenvolvimento de software?
Que o formato é uma decisão sobre risco e confiança, e que nenhum estudo aponta um vencedor. Os três trabalhos abaixo são anteriores a 2025, mas são o que a literatura acadêmica tem de medição direta sobre esse tema.
Patrick Bajari e Steven Tadelis publicaram em 2001, no RAND Journal of Economics, um modelo em que o comprador troca incentivo por custo de renegociação. Os autores mostram que o contrato por custo é preferível ao preço fechado quando o projeto é mais complexo. A lógica é que, num projeto complexo, o desenho muda depois da assinatura, e renegociar um preço fechado tem custo próprio.
O dado empírico mais útil é de Lior Fink, Yossi Lichtenstein e Simon Wyss, publicado em 2013 na Applied Economics. Eles analisaram 270 contratos de desenvolvimento de software assinados entre janeiro de 2000 e abril de 2003 por um banco internacional, com cerca de 100 fornecedores. Foram 139 contratos de preço fechado padrão (51%), 42 de preço fechado rígido (16%), 43 por hora puro (16%), 14 por hora com teto (5%) e 32 mistos (12%). Os mistos tinham preço médio de US$ 632 mil, contra US$ 284 mil do preço fechado padrão. Segundo os autores, preço maior, que eles usam como indicador de incerteza, aparece junto de contratos menos completos.
Esse estudo mede o tipo de contrato, não o resultado do projeto. Ele vem de um único banco. Serve para mostrar que, mesmo num comprador grande em que dois terços dos contratos eram a preço fechado, 17% usaram formatos mistos ou por hora com teto, e os mistos custavam em média mais que o dobro do preço fechado padrão.
O terceiro trabalho é de Yossi Lichtenstein e Alan McDonnell, apresentado em 2003 na conferência europeia de sistemas de informação (ECIS). A hipótese era que projetos arriscados seriam contratados por hora e os demais a preço fechado. Em 14 projetos externos de duas grandes empresas, os dados não sustentaram a hipótese. Nas entrevistas com gerentes seniores, uma das empresas contratava os projetos arriscados a preço fechado e pagava um prêmio de risco para não precisar refazer o orçamento. A outra só aceitava preço fechado com fornecedor de confiança.
O que se tira daí: o critério não é o formato. É quem aceita carregar o quê, e com que grau de confiança.
Por que o preço fechado fica caro quando o pedido está vago?
Porque os estouros de custo em software são raros, mas enormes, e alguém precisa pagar por eles.
Bent Flyvbjerg e colegas compararam 23 tipos de projeto num estudo do volume 57 (2026) do Project Management Journal, com 11.011 projetos. Dos 5.360 projetos de TI da amostra, 40,86% estouraram o orçamento. Em 18,26% o estouro passou de 50%, e nesses casos o custo final médio foi 5,53 vezes a estimativa. Os autores concluem que TI é o único tipo cuja cauda de estouros é pesada a ponto de tornar o risco imprevisível, e propõem como explicações o caráter sob medida do software e decisões tomadas depressa demais. Como remédio, sugerem modularidade e decidir com mais calma.
A conexão com o contrato é nossa leitura, não um resultado do estudo. Um fornecedor que conhece essa cauda tende a colocar uma reserva no preço fechado quando o pedido é vago, e você paga essa reserva mesmo que o projeto corra bem. Quando o pedido é bem descrito, a reserva encolhe, porque o que o fornecedor não sabe diminui. O custo do preço fechado, então, depende menos da negociação e mais de quanto você conseguiu decidir antes de pedir.
Por isso o problema raramente é de contrato. Você não tem um problema de preço fechado ou por hora. Você tem um problema de arquitetura: o pedido ainda não sabe o que é.
Como dividir a incerteza em vez de escolher um lado?
Separando o pedido em duas pilhas e dando a cada uma o contrato que combina com ela.
Na primeira pilha ficam as partes decididas: telas, fluxos e regras que alguém consegue descrever e validar. Essas combinam com preço fechado, de preferência divididas em módulos pequenos, com entregas intermediárias. No estudo de Fink e colegas, mais entregas intermediárias aparecem junto de contratos mais completos, o que faz sentido: cada entrega é uma data em que as duas partes conferem o que foi combinado.
Na segunda pilha ficam as partes a descobrir: a regra que só um funcionário conhece, a integração com um sistema que ninguém documentou. Essas combinam com uma fase curta de descoberta a preço fechado, cuja entrega é um documento de regras e um mapa de integrações. O que a descoberta documenta passa para a primeira pilha. O que continua incerto depois dela vai por hora com teto, e o teto é o que impede que o formato por hora vire cheque em branco.
Há um passo anterior que reduz a segunda pilha por conta própria. Rodar o processo na mão por três semanas antes de assinar transforma parte do que era incerteza em registro, e o registro vira especificação. Quanto mais o pedido se parece com uma especificação, mais o preço fechado fica justo para os dois lados.
Falta uma regra escrita para mudança de escopo: quem pode pedir, quem aprova, como o impacto em prazo e valor é informado antes da execução. Sem ela, os dois formatos produzem a mesma discussão, só em momentos diferentes.
Como isso fica numa operação real?
Considere um cenário hipotético: uma distribuidora de médio porte quer um portal de pedidos para substituir a planilha e o WhatsApp do time comercial. Duas coisas estão decididas: o cadastro de clientes e o fluxo do pedido, do envio à aprovação. Duas não estão: a regra de preço por cliente, que hoje vive na cabeça do gerente comercial, e a integração com o controle de estoque, mantido numa planilha.
Uma proposta única a preço fechado obriga o fornecedor a adivinhar as duas incertezas e a precificá-las. Uma divisão mais clara teria três blocos. Primeiro, duas a três semanas de descoberta a preço fechado, com entrega de regras de preço documentadas e mapa de integração com o estoque. Segundo, o módulo de cadastro e pedidos a preço fechado, já com o que a descoberta revelou. Terceiro, a regra de preço e a integração: a preço fechado, se a descoberta conseguiu documentá-las, ou por hora com teto e revisão a cada entrega, se a planilha de estoque ainda guardar regras que ninguém sabe descrever.
Os prazos acima são ilustração, não medição. O ponto é a estrutura: a incerteza aparece cedo, em um bloco curto e barato, em vez de aparecer na semana oito dentro de um preço que já foi pago.
Os cases da Yowpi mostram uma sequência próxima, embora não registrem o formato de contrato usado. A Colo Saúde começou com um resgate delimitado, auditoria de segurança e ajuste de performance, que levou a segurança de 7/10 para 10/10 na auditoria da própria Yowpi e cortou em 60% o consumo de unidades de processamento do Bubble (WUs). Os projetos seguintes vieram depois, com a confiança estabelecida. A UniTrust começou com um sistema no ar em duas semanas, em agosto de 2022, e a plataforma evoluiu em sequência até cobrir o ciclo inteiro do agente. Nos dois, a entrega inicial foi pequena e verificável, e a ampliação veio depois dela.
Perguntas frequentes
Preciso de alguém técnico na empresa para avaliar um contrato de software?
Não necessariamente. A avaliação técnica do código ou da arquitetura pode ser contratada. O que só você tem é a resposta para "o que está decidido e o que não está". Peça ao fornecedor, por escrito, a lista do que ele considerou fora do preço e do que ele supôs sobre os sistemas que você já usa. Essa lista é mais útil do que qualquer cláusula.
O preço fechado não protege melhor o meu caixa?
Protege o caixa, não necessariamente o resultado. O valor está definido, mas o que cabe nele depende de quão bem o pedido foi descrito, e o que ficou de fora volta como aditivo. Há compradores que aceitam pagar um prêmio de risco por previsibilidade, como mostram as entrevistas de Lichtenstein e McDonnell. É uma escolha legítima, desde que feita sabendo o que o prêmio cobre.
E se a integração com o que já uso for mais complicada do que o previsto?
É o caso mais comum de incerteza escondida, e por isso merece tratamento próprio. Faça a descoberta antes, para que o fornecedor veja o sistema existente antes de precificar, e deixe por hora com teto só o que ela não conseguir esclarecer. Se o teto estourar, você descobre cedo, num bloco pequeno, e decide com dados.
O próximo passo
Se você tem uma proposta na mesa e não sabe se o formato combina com o que já está decidido, o Diagnóstico de Arquitetura Operacional, uma conversa de 30 minutos, ajuda a separar o que pode ser fechado agora do que ainda precisa ser descoberto, e você sai com essa lista: fale com um arquiteto.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico