SobreProjetosServiços BlogFAQContato
Início/Blog/Custos e prazos
Custos e prazos

Recebi 3 orçamentos muito diferentes: como decidir

Método para comparar propostas de software item a item, normalizar escopo e premissas, e identificar quais orçamentos vão virar aditivo lá na frente.

19 de fev. de 2026 5 min de leitura por Natiam Gabriel
Recebi 3 orçamentos muito diferentes: como decidir
Resposta curta

Diferença grande entre propostas quase nunca é margem, é escopo diferente. Antes de comparar preço, normalize: envie a mesma lista de entregáveis e as mesmas premissas para os três e peça que reprecifiquem. Só depois o número significa alguma coisa.

Pare de comparar os números. Quando três propostas para o mesmo pedido variam muito, a causa quase nunca é margem: é que cada fornecedor precificou um projeto diferente. Antes de decidir, você precisa fazer com que os três estejam orçando exatamente a mesma coisa. Só depois disso o preço vira informação útil.

Por que a diferença raramente é ganância

Um pedido escrito em duas páginas admite muitas leituras. Considere "sistema de pedidos com área do cliente". Três fornecedores competentes podem interpretar assim:

  • Fornecedor A: seis telas, cadastro simples, sem migrar dados antigos, publicação em hospedagem compartilhada
  • Fornecedor B: as mesmas seis telas, mais importação da base atual, testes automatizados, controle de permissão por perfil e treinamento
  • Fornecedor C: tudo do B, mais integração com o ERP, emissão fiscal e aplicativo para o vendedor externo

Nenhum está errado. Os três responderam ao que entenderam. A diferença de preço reflete a diferença de trabalho, e não a diferença de honestidade. O erro está no pedido, que era ambíguo o bastante para permitir as três leituras.

Existe uma segunda fonte de diferença: quanto cada um está disposto a assumir de risco. Quem vê muita incerteza embute margem maior ou se recusa a fechar preço. Isso também não é ganância, é gestão de risco.

Como normalizar as três propostas

O processo é chato e leva cerca de duas horas. Ele costuma mudar completamente o ranking.

  1. Extraia a lista de entregáveis de cada proposta, item por item, na planilha.
  2. Una tudo numa lista só. Se o fornecedor B previu migração de dados e os outros não, migração entra na lista.
  3. Escreva as premissas que você consegue confirmar: quantos usuários, quantos perfis de acesso, quantos registros para migrar, quais integrações existem de fato.
  4. Devolva essa lista única aos três e peça reprecificação item a item, com prazo por bloco.
  5. Peça que marquem o que consideram fora do escopo e o custo separado de cada exclusão.

O que acontece a seguir é previsível: a distância entre as propostas encolhe muito. Suponha um cenário típico em que as propostas chegaram a R$ 45 mil, R$ 90 mil e R$ 160 mil. Depois de normalizadas, é comum que fiquem em algo como R$ 95 mil, R$ 105 mil e R$ 140 mil. Aí sim você está escolhendo fornecedor, não interpretação.

A tabela de comparação que você deve preencher

Uma linha por bloco de trabalho, uma coluna por fornecedor. Preencha com horas e com valor.

Bloco Fornecedor A Fornecedor B Fornecedor C
Levantamento e desenho de telas
Cadastros e regras de negócio
Integrações com sistemas existentes
Migração da base atual
Perfis de acesso e permissões
Relatórios
Testes automatizados
Implantação e ambiente de produção
Treinamento e documentação
Garantia e suporte pós-entrega
Gestão do projeto

As linhas que ficarem em branco em uma coluna e preenchidas em outra são exatamente onde está a diferença de preço. Elas não são gordura de quem cobrou mais: são trabalho que quem cobrou menos não vai fazer, ou vai fazer e cobrar depois.

Preste atenção especial em quatro linhas: migração, integrações, testes e implantação. É onde a maioria dos aditivos nasce.

As perguntas que revelam a qualidade da proposta

Faça as mesmas seis perguntas para os três e compare as respostas, não a eloquência.

  • O que exatamente está fora do escopo desta proposta? Quem responde com uma lista clara pensou no projeto. Quem responde "nada, está tudo incluso" ainda não olhou direito.
  • Quais premissas o preço assume? Volume de dados, número de perfis, existência de documentação da API do ERP, ambiente de testes disponível.
  • O que acontece se uma premissa cair? Deve haver um mecanismo previsto, não uma renegociação do zero.
  • Qual o maior risco do projeto na sua opinião? Fornecedor que aponta risco é mais confiável que fornecedor com certeza absoluta.
  • Como funciona a entrega? Marcos com entregas parciais utilizáveis são melhores que uma entrega única no fim.
  • O que acontece depois da entrega? Garantia de quanto tempo, cobrindo o quê, e qual o custo mensal de manutenção.

Essa última pergunta separa muito. Um sistema tem custo de vida, não só de nascimento: hospedagem, certificados, atualizações de segurança, correções. Proposta que ignora isso está deixando um custo para você descobrir sozinho no terceiro mês.

Sinais de que a proposta vai virar aditivo

Sinal na proposta O que costuma significar
Preço fechado sem lista de premissas O fornecedor vai descobrir o escopo real durante a execução
"Integração com o sistema atual" sem nomear o sistema nem a forma Ninguém verificou se existe API disponível
Migração de dados citada em uma linha, sem volume A base real quase sempre está mais suja que o previsto
Prazo redondo demais, tipo "60 dias" para tudo Prazo derivado da expectativa do cliente, não do escopo
Nenhuma menção a testes Correção de defeito vai virar hora extra depois da entrega
Nenhuma menção a implantação e ambiente Publicar, configurar e monitorar não foi contado
Escopo descrito só por telas O trabalho invisível, regras, validações e permissões, ficou de fora
Valor muito abaixo dos outros dois, sem explicar por quê Ou entendeu menos, ou vai cortar em algum lugar
Nenhuma pergunta feita antes de orçar Ninguém orça bem o que não perguntou

O último é o mais confiável de todos. Um fornecedor que enviou proposta sem fazer nenhuma pergunta orçou uma suposição.

Como decidir quando os preços empatam

Depois de normalizar, é comum sobrarem duas propostas próximas. Aí os critérios de desempate são outros:

  • Entrega em marcos utilizáveis. Você consegue usar algo em 6 semanas ou só no final?
  • Onde fica o código. Repositório na sua organização, desde o primeiro dia, é diferente de receber um zip no fim.
  • Quem toca o projeto. Nome e disponibilidade real, não "nossa equipe".
  • Como se comunica. Reunião semanal curta e registro escrito valem mais que promessa de disponibilidade total.
  • O que acontece se vocês se separarem. Documentação, acessos e transição precisam estar previstos antes do contrato, não depois da briga.

Uma forma prática de reduzir o risco quando ainda há dúvida: contrate uma fase de descoberta curta e paga, de uma a três semanas, do fornecedor que mais convenceu. A entrega é escopo detalhado, premissas confirmadas e estimativa firme. Você paga pouco para transformar incerteza em número, e sai com um documento que serve para orçar com qualquer um, inclusive com os outros dois.

Perguntas frequentes

Por que um orçamento é três vezes maior que o outro para o mesmo sistema?

Porque os três leram pedidos diferentes no mesmo texto. Um contou só as telas, outro incluiu migração de dados, testes e implantação, e o terceiro assumiu integrações que ninguém mencionou. Sem uma lista igual de entregáveis, você está comparando projetos distintos com o mesmo nome.

Devo escolher sempre o orçamento mais barato?

Não, e também não o mais caro por segurança. O mais barato costuma ser o que enxergou menos trabalho, e o que não foi visto agora aparece como aditivo depois. Escolha o que declara premissas, lista entregáveis e nomeia riscos, mesmo que fique no meio da faixa de preço.

É normal um fornecedor se recusar a dar preço fechado?

É normal e frequentemente é um bom sinal, quando o escopo ainda está vago. A alternativa saudável é uma fase de descoberta paga e curta que produz escopo detalhado, e só então um preço fechado. Preço fechado sobre ideia vaga acaba em prejuízo para um dos dois lados.

Tem um processo que consome o time?

Me conta como funciona hoje. Se der para automatizar, eu te digo por onde começar — a conversa de diagnóstico não é cobrada.

Natiam Gabriel
Sobre o autor

Natiam Gabriel é AI Engineer & Full-Stack Developer e fundador da Retti Tech, estúdio de desenvolvimento de software que atende empresas em todo o Brasil. Constrói sistemas web sob medida, automações e integrações, com ou sem inteligência artificial, do levantamento de requisitos até a operação em produção. Mais de 20 empresas usam em produção os sistemas que desenvolveu.