É normal receber propostas com valores três vezes diferentes?

Sim, e na maioria das vezes o motivo é que cada fornecedor entendeu um escopo diferente a partir do mesmo briefing. Diferenças de senioridade, estrutura de custo e apetite a risco explicam parte, mas raramente uma variação dessa magnitude sozinhas. A forma de descobrir é comparar entregáveis nominais, não valores totais.

A proposta mais barata é sempre pior?

Não necessariamente, mas ela precisa ser explicada. Pode ser um profissional com menos estrutura e custo fixo menor, ou pode ser alguém que deixou de fora migração de dados, testes, tratamento de erro e implantação. Peça a lista do que está incluído e o que não está, e compare item a item antes de concluir.

Como comparar propostas de desenvolvimento de forma justa?

Envie o mesmo documento de escopo a todos, exija a mesma estrutura de resposta com entregáveis nominais e premissas declaradas, e pergunte explicitamente sobre migração, garantia, propriedade do código e o que acontece com pedidos fora do escopo. Depois compare os itens, não os totais.

Por que dois orçamentos de software variam tanto

Quando três fornecedores respondem ao mesmo pedido com R$ 30 mil, R$ 90 mil e R$ 180 mil, a explicação quase nunca é ganância ou incompetência. Eles estão orçando coisas diferentes, porque o pedido permitia interpretações diferentes. Descobrir qual é qual é um trabalho que cabe a quem contrata.

As cinco causas reais da variação

1. Interpretações diferentes do mesmo texto. "Sistema de gestão de pedidos" pode ser um formulário com uma listagem ou uma plataforma com regras de desconto, aprovação em duas etapas, reserva de estoque e integração fiscal. Todos leram a mesma frase. Um imaginou três semanas de trabalho; outro imaginou seis meses. Essa é, com folga, a causa dominante.

2. Itens invisíveis incluídos ou não. Alguns fornecedores contam migração de dados, testes automatizados, implantação, treinamento e documentação. Outros orçam só o desenvolvimento e cobram o resto depois. A diferença entre esses dois orçamentos pode passar de 50% sem que nenhum dos dois esteja mentindo.

3. Risco precificado de formas diferentes. Diante de incerteza, um fornecedor coloca margem de segurança e outro assume o valor otimista para ganhar o contrato. O segundo aparece mais barato na planilha e vira aditivo no meio do projeto.

4. Estrutura de custo do fornecedor. Um profissional autônomo trabalhando de casa e uma consultoria com escritório, comercial, gestão de projeto e jurídico têm custos fixos incomparáveis. Parte disso você compra em forma de previsibilidade e capacidade de substituir pessoas; parte é apenas custo.

5. Nível técnico e velocidade. Duas pessoas com valores-hora parecidos podem levar tempos muito diferentes para o mesmo trabalho, e a diferença de retrabalho não aparece em nenhuma proposta. É por isso que comparar valor-hora isolado engana.

Como padronizar o pedido para poder comparar

A maior parte da variação é responsabilidade de quem pede, não de quem responde. Um documento de escopo de duas a quatro páginas, enviado igual a todos, resolve boa parte do problema. Ele deve conter:

O problema de negócio, em uma frase, e o que muda se ele for resolvido.
Quem usa o sistema e quantas pessoas de cada perfil.
A lista de funcionalidades, separada em obrigatórias para a primeira entrega e desejáveis para depois.
Os sistemas a integrar, com nome, versão e se você já tem acesso à API.
Volume de dados: quantos registros hoje, quantos por mês.
Migração: existe base antiga? Em qual formato?
Restrições reais: data limite, exigência legal, tecnologia obrigatória por política interna.
O que está fora de escopo, explicitamente. Essa seção evita mais mal-entendido do que todas as outras.

Peça, também, que todas as propostas sigam a mesma estrutura de resposta. Sem isso você compara documentos incomparáveis.

O que toda proposta precisa responder

Item	Por que importa
Lista nominal de módulos e telas	Revela o escopo que o fornecedor entendeu
Integrações incluídas e excluídas	É o item mais comum de "achei que estava incluído"
Migração de dados: sim ou não	Pode representar 15% a 30% do projeto
Perfis de usuário e permissões	Multiplica o esforço de forma silenciosa
Testes e homologação	Quem testa, com quais dados, e quanto tempo dura
Implantação e treinamento	Software entregue não é software em uso
Garantia: prazo e o que cobre	Separa defeito de pedido novo
Preço de trabalho fora do escopo	Evita negociação tensa no meio do projeto
Propriedade de código, dados e acessos	Define se você contratou um sistema ou uma dependência
Premissas assumidas	Onde mora a diferença entre as propostas

A última linha é a mais reveladora. Uma proposta que declara premissas, "assumimos que a API do ERP está documentada", "assumimos até três perfis de acesso", "assumimos migração de até 50 mil registros", permite entender exatamente onde ela diverge das outras. Proposta sem premissa declarada é um número sem contexto.

Sinais de alerta em qualquer proposta

Valor único, sem decomposição. "Sistema completo: R$ 120 mil." Não dá para negociar, cortar ou entender. Peça a quebra por módulo ou fase.

Prazo redondo demais. "Três meses" para um escopo que não foi detalhado costuma indicar que ninguém estimou de verdade.

Ausência de menção a migração e testes. Se não está escrito, não está incluído, independentemente do que foi dito em reunião.

Silêncio sobre propriedade e acessos. Você deve ficar com o código, o banco, o domínio e as credenciais. Se a proposta não diz isso, pergunte por escrito.

Concordância imediata com prazo apertado. Um fornecedor que aceita qualquer data sem discutir escopo não está sendo flexível; está adiando o conflito.

Desconto grande sem redução de escopo. Se 30% podiam sair do preço sem tirar nada da entrega, o preço inicial não tinha base, ou a redução vai sair de algum lugar que você não está vendo.

Como decidir depois de comparar

Quando as propostas estiverem no mesmo formato, a decisão raramente é sobre o menor preço. Três critérios costumam prever melhor o resultado:

Quem fez as melhores perguntas. O fornecedor que questionou seu briefing, apontou contradição e sugeriu cortar algo entendeu o problema. Quem só devolveu preço, não.

Quem mostrou trabalho comparável. Não vale reputação genérica: peça um caso com desafio parecido, mesmo tipo de integração, mesma ordem de volume, mesmo grau de regra de negócio.

Quem explicou o risco em vez de escondê-lo. Uma proposta que diz "esta parte depende da API do fornecedor X e pode variar" é mais confiável que uma que finge certeza total.

Se ainda restar dúvida entre duas, contrate uma fase de descoberta paga e curta com a favorita. Duas a quatro semanas produzindo escopo detalhado custam pouco, geram um documento reutilizável mesmo que você troque de fornecedor, e são o teste de convivência mais barato disponível.