# Orçamento de sistema interno: por que os preços variam tanto > Três orçamentos para o mesmo sistema chegam distantes porque cada um leu um acoplamento diferente na sua operação. Veja o que perguntar antes de comparar. - Autor: Marlon Trettin - Publicado: 2026-10-17 · Atualizado: 2026-10-17 - Idioma: pt-BR - Canonical: https://yowpi.com/blog/orcamento-de-sistema-interno-por-que-os-precos-variam --- Três orçamentos para o mesmo sistema chegam com preços distantes porque cada fornecedor leu um grau diferente de acoplamento na sua operação. O preço não mede o tamanho da tela. Mede quantas coisas o fornecedor acha que vai precisar mexer para a tela funcionar. A diferença entre as propostas é informação sobre o seu pedido. ## TL;DR - Entre 23 tipos de projeto comparados por [Flyvbjerg e colegas em 2026](https://journals.sagepub.com/doi/10.1177/87569728251340590), TI é um dos que menos estouram orçamento: 41% passam do previsto, contra 74% em prédios e 97% em usinas nucleares. - Quando estoura, estoura grande. Nos 18% de projetos de TI que passam de 50% do orçamento, o custo final médio é 5,53 vezes a estimativa, o maior índice dos 23 tipos. - O mesmo grupo de pesquisa propõe o [mecanismo por trás disso](https://arxiv.org/pdf/2210.01573): interdependência entre componentes. Um problema numa peça se propaga para tudo que está acoplado a ela. Isso é arquitetura, não azar. - Comparar três preços não informa quase nada. Comparar as três leituras de acoplamento por trás dos preços informa quase tudo. ## Por que três fornecedores leem o mesmo pedido e respondem preços tão distantes? Porque o seu pedido descreve a tela e o preço deles descreve o que fica atrás dela. "Preciso de um sistema de pedidos" é uma frase completa para quem opera e uma frase ambígua para quem orça. Ela não diz se o pedido nasce do vendedor em campo ou do cliente, se o estoque precisa responder na hora, se o preço vem de uma tabela ou de uma regra por cliente, se a nota sai do mesmo lugar. Cada fornecedor responde essas perguntas sozinho, em silêncio, e cobra pela resposta que deu. O barato costuma ter respondido "isso é uma tela de cadastro". O caro costuma ter respondido "isso encosta no estoque, no financeiro e na emissão fiscal". Os dois estão orçando com honestidade. Estão orçando projetos diferentes. A dispersão, então, não é um problema de mercado. É um retrato de quanta coisa ficou sem ser dita no seu pedido. ## O que a pesquisa mostra sobre o risco de custo em software? Que o risco não está na média. Está na cauda. Bent Flyvbjerg e colegas compararam [23 tipos de projeto em estudo publicado em 2026](https://journals.sagepub.com/doi/10.1177/87569728251340590), com 5.360 projetos de TI na amostra. Projeto de TI estoura o orçamento em 40,86% dos casos, uma das três menores frequências da tabela inteira. Prédios estouram em 73,66%. Túneis, em 73,91%. Usinas nucleares, em 96,94%. Olimpíadas, em 100%. Esse primeiro número contraria o senso comum de que software sempre atrasa e sempre custa mais. Na maior parte das vezes, o orçamento fecha. O segundo número é o que importa. Entre os projetos de TI, 18,26% estouram em mais de 50%, e nesses casos o custo final médio é 5,53 vezes a estimativa inicial. Esse 5,53 é o mais alto dos 23 tipos comparados, acima de armazenamento nuclear, de defesa e das Olimpíadas. A mesma tabela mostra a assinatura estatística disso: em TI, a média de estouro fica 73 pontos percentuais acima da mediana. Traduzindo para a sua decisão: a chance de o orçamento fechar é razoável, e a conta do dia em que não fecha é de outra ordem de grandeza. Quem escolhe fornecedor olhando só para o preço está otimizando a parte fácil do problema. ## De onde vem a cauda? De acoplamento. O trabalho que destrinchou o mecanismo por trás dessa distribuição vem do mesmo grupo de pesquisa e trabalha sobre a mesma base de projetos de TI, num recorte de [5.392 projetos](https://arxiv.org/pdf/2210.01573). Não são duas evidências independentes, e sim dois cortes do mesmo conjunto. A explicação que eles propõem é a interdependência entre componentes: um problema numa peça dispara reação em cadeia nas peças ligadas a ela, e é essa propagação que produz os estouros extremos. Esse estudo traz dois achados que vale guardar. O primeiro é que estouros e economias aparecem com frequência parecida, o que reforça que a estimativa inicial é uma faixa, não um número. O segundo está numa nota de rodapé: o maior estouro de toda a amostra não foi um megaprojeto. Foi uma customização pequena de workflow, orçada em 1.500 dólares, que terminou em 425 mil dólares. Guarde esse par. Escopo pequeno e operação acoplada é a combinação que produz a conta grande. E uma operação que acumulou sistemas comprados em épocas diferentes é exatamente o ambiente onde o acoplamento mora sem ser visto. É por isso que a pergunta certa antes de comparar preços não é "quanto custa construir isso". É "quantas coisas isso encosta". ## Quem está avaliando a proposta do seu lado da mesa? Em muitas empresas, ninguém cuja função seja essa. A [TIC Empresas 2025](https://cetic.br/pt/tics/pesquisa/2025/empresas/F4/), do Cetic.br, mostra que 37% das empresas brasileiras que terceirizam funções de TIC terceirizam desenvolvimento de aplicações. Dentro desse mesmo grupo, a proporção é de 34% entre as empresas de 10 a 49 pessoas ocupadas e de 62% entre as de 250 ou mais. A mesma pesquisa mede o outro lado da mesa. Entre as empresas que [não têm área ou departamento de TI](https://cetic.br/pt/tics/pesquisa/2025/empresas/F1A/), 89% também não têm nenhum especialista em tecnologia da informação. Nas de 10 a 49 pessoas ocupadas, a proporção se repete. A leitura combinada é direta. Uma parte relevante das empresas contrata desenvolvimento fora, e boa parte delas não tem, dentro de casa, ninguém cuja profissão seja ler proposta técnica. A decisão cai no colo de quem entende de operação, e a única variável comparável entre três documentos técnicos passa a ser o preço. Na maior parte das PMEs, esse papel não tem dono declarado no organograma. Dá para cobrir esse vazio sem contratar ninguém, desde que você mude o que pede. ## Como comparar três orçamentos que não medem a mesma coisa Peça a cada fornecedor a lista do que ele vai encostar. Não a lista de funcionalidades, que todos escrevem igual. A lista dos sistemas, planilhas, rotinas e pessoas que precisam mudar de comportamento para o sistema novo funcionar. Quatro perguntas dão conta da maior parte da dispersão: Quais sistemas que já existem aqui esta proposta lê ou escreve? Quem responde "nenhum" está propondo mais uma ilha, e ilha é barata na entrega e cara na conta de três anos. O que acontece quando um desses sistemas muda ou sai do ar? A resposta separa quem pensou em acoplamento de quem vai descobrir isso durante o projeto. Qual parte desta proposta é premissa e qual é compromisso? Premissa que ninguém marcou como premissa vira aditivo depois. O que foi deixado de fora de propósito? Fornecedor sênior responde essa com rapidez e com uma lista. Quem não tem a lista não desenhou fronteira nenhuma. Se as três respostas vierem diferentes, você não tem três preços. Tem três escopos, e agora dá para escolher qual deles é o seu. Um cenário para tornar isso concreto, apresentado como hipótese de trabalho e não como medição de cliente nosso: uma distribuidora com 60 funcionários pede um sistema de pedidos. O fornecedor A orça a tela de pedido e a lista. O B inclui leitura do estoque em tempo real. O C inclui estoque, a regra de preço por cliente e o gatilho da emissão fiscal. Os três preços vão estar distantes, e nenhum dos três está errado. Errado está o pedido que permitiu as três leituras. Meia hora desenhando a fronteira antes de pedir orçamento move mais dinheiro do que qualquer negociação depois. Esse desenho de fronteira é a mesma disciplina que separa [comprar de construir](/blog/comprar-ou-construir-como-decidir) e a que define [o custo de manter o sistema depois de pronto](/blog/custo-de-manter-um-sistema-depois-de-pronto). No resgate da plataforma da [Colo Saúde](/cases/colo-saude), o primeiro projeto não foi construir: foi auditar a segurança e ajustar a performance de uma plataforma herdada que estava sem dono técnico. A Yowpi também emite orçamento, e as quatro perguntas acima servem para avaliar o nosso do mesmo jeito que servem para avaliar o dos outros. Proposta que não sobrevive a elas não merece assinatura, venha de quem vier. ## Perguntas frequentes **O orçamento mais barato propõe no-code. A diferença de preço está só na ferramenta?** Raramente. A ferramenta explica uma parte da diferença, e a fronteira de escopo explica a maior. Compare primeiro o que cada proposta encosta na sua operação. Se os dois fornecedores tocarem o mesmo conjunto de sistemas e rotinas, aí a comparação entre abordagens passa a ser honesta, e aí ela é uma decisão técnica legítima. **A integração com o que já uso vai ser complicada. Isso aparece no orçamento?** Aparece, quase sempre na forma de premissa. Procure frases como "considerando que o ERP disponibiliza API" ou "assumindo acesso ao banco". Cada uma dessas linhas é um risco que ficou do seu lado sem estar precificado. Peça que cada premissa venha com o que acontece se ela não se confirmar. **Não tenho equipe qualificada para avaliar proposta técnica. O que faço?** Você não precisa avaliar a arquitetura. Precisa comparar escopos, e isso você faz melhor do que qualquer fornecedor, porque conhece a operação. Peça as quatro perguntas deste artigo por escrito e leia as respostas como quem lê descrição de processo. Onde a resposta ficar vaga sobre o que o sistema encosta, está o risco. ## O próximo passo Se você está com propostas na mesa e preços que não conversam entre si, o [Diagnóstico de Arquitetura Operacional](/contato) de 30 minutos ajuda a desenhar a fronteira antes da assinatura. Traga os orçamentos.