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.
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.
- Extraia a lista de entregáveis de cada proposta, item por item, na planilha.
- Una tudo numa lista só. Se o fornecedor B previu migração de dados e os outros não, migração entra na lista.
- Escreva as premissas que você consegue confirmar: quantos usuários, quantos perfis de acesso, quantos registros para migrar, quais integrações existem de fato.
- Devolva essa lista única aos três e peça reprecificação item a item, com prazo por bloco.
- 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 é 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.