Orçamento de software sob medida: por que três propostas chegam com preços tão diferentes (e como comparar sem cair em cilada)

Você mandou o mesmo pedido para três fornecedores. Um sistema para controlar pedidos, estoque e emissão de nota, com acesso para a equipe e um painel para o dono. Voltaram três propostas: uma de R$ 28 mil, uma de R$ 95 mil e uma de R$ 210 mil. Mesmo briefing, mesma reunião, a mesma lista de funcionalidades. Agora você está com as três abertas na tela e nenhuma referência para decidir. A mais barata parece boa demais. A mais cara parece exagero. A do meio parece segura só porque está no meio. Quem já passou por um projeto travado sabe do que estou falando: escolher pelo preço, sem entender o que cada número contém, é o jeito mais comum de começar mal.

Por que orçamentos de software sob medida variam tanto

A variação não é sinal de que alguém está mentindo. É sinal de que cada fornecedor respondeu a uma pergunta diferente. Software sob medida não tem preço de tabela porque o produto ainda não existe: o que se cobra é uma estimativa de horas multiplicada por um custo de hora, mais uma margem para o que ninguém previu. Três coisas fazem o número andar.

• Interpretação do escopo. "Controle de estoque" pode ser uma tabela com entrada e saída ou pode ser multi-depósito, com lote, validade e integração com o fiscal. O fornecedor barato leu a primeira versão. O caro leu a segunda. Nenhum dos dois perguntou qual era a sua.
• Senioridade de quem executa. Uma hora de dev júnior custa um terço da hora de um sênior e rende bem menos que um terço. O orçamento baixo costuma esconder um time que vai aprender no seu projeto.
• O que está fora do número. Design, testes, publicação, hospedagem, suporte após a entrega, documentação. Cada proposta inclui um conjunto diferente dessas etapas e raramente deixa claro qual.

Não existe resposta única, mas existe conta certa. E a conta começa por saber o que cada proposta realmente comprou.

Quanto custa um sistema web sob medida em 2026: faixas reais

Para dar referência, estas são as faixas que vemos no mercado brasileiro para sistemas web feitos por equipe sênior. Não são tabela, são ordem de grandeza.

• Sistema interno simples (cadastros, um fluxo principal, dois ou três perfis de usuário, relatórios básicos): R$ 30 mil a R$ 70 mil, 6 a 10 semanas.
• Sistema operacional de porte médio (vários módulos que conversam, integração com um ou dois sistemas externos, permissões por área, painéis): R$ 80 mil a R$ 200 mil, 3 a 5 meses.
• Plataforma com clientes externos (portal ou app para o público, pagamento, notificações, volume alto de acessos): a partir de R$ 200 mil, 5 meses ou mais.

O que move o número dentro de cada faixa: quantidade de integrações, complexidade das regras de negócio (cálculo de comissão com dez exceções custa mais que cadastro de cliente), necessidade de migrar dados de um sistema antigo e nível de acabamento visual. Uma integração com ERP que tem API documentada leva uma semana. A mesma integração com um ERP que só exporta arquivo por e-mail leva três.

Some a isso o custo recorrente. Hospedagem, monitoramento e correções depois da entrega ficam, em geral, entre 10% e 20% do valor do projeto por ano. Proposta que não menciona isso não está errada, está incompleta.

O que cada proposta esconde: os 8 itens que precisam estar no papel

Antes de comparar preço, coloque as três propostas lado a lado e marque o que cada uma responde. Se o documento não diz, a resposta é "não incluído" até prova em contrário.

1. Lista de funcionalidades com detalhe. Não "módulo de estoque", mas o que o módulo faz, fluxo por fluxo. Sem isso, o preço não tem base.
2. O que está explicitamente fora. Uma proposta séria diz o que não vai fazer. É a única forma de saber que o fornecedor entendeu os limites.
3. Design incluído ou não. Tela desenhada antes do código ou tela improvisada durante. A diferença aparece no uso diário da equipe e no retrabalho.
4. Quem vai executar. Nomes, papéis, senioridade. "Time dedicado" sem nome é um time que ainda não existe.
5. Entregas parciais e marcos. Em que semana você vê algo funcionando? Projeto de quatro meses sem entrega intermediária é projeto que você só descobre errado no fim.
6. Propriedade do código, contas e dados. Repositório, servidor e domínio em nome de quem? Isso decide se você pode trocar de fornecedor depois.
7. Garantia e suporte pós-entrega. Quantos dias de correção sem custo, e quanto custa o mês de manutenção depois.
8. Como tratam mudança de escopo. Vai acontecer. A proposta precisa dizer como a mudança é orçada e aprovada, senão vira briga.

Depois desse exercício, o barato costuma ficar menos barato e o caro costuma ficar mais explicável. Às vezes o do meio some, porque não respondeu a metade da lista.

Sinais de que a proposta barata vai sair cara (e de que a cara está inflada)

O barato que sai caro aqui é o seguinte: o fornecedor fecha abaixo do custo para ganhar o contrato e recupera a margem de três formas. Cobrando cada ajuste como "fora do escopo". Colocando gente menos experiente. Ou, no pior caso, deixando o projeto travar até você aceitar um aditivo. Alguns sinais aparecem antes da assinatura.

• Preço fechado sem nenhuma pergunta sobre a operação. Quem não perguntou não entendeu, e quem não entendeu chutou.
• Prazo curto demais para o tamanho do escopo. Sistema de porte médio em quatro semanas não é eficiência, é escopo que vai ser cortado depois.
• Proposta genérica, com o nome da sua empresa trocado no cabeçalho.
• Ausência total de custos recorrentes. Ou o fornecedor não opera sistemas em produção, ou vai cobrar depois.
• Pagamento 100% adiantado ou, no outro extremo, 100% no final. Os dois indicam que o fornecedor não confia no próprio cronograma.

O caro também merece pergunta. Se a proposta de R$ 210 mil inclui um app nativo que ninguém pediu, um portal de cliente que só faz sentido daqui a dois anos e um "módulo de BI" para um relatório de vendas, você está pagando por escopo que não precisa. Fornecedor honesto tira coisa da proposta. Uma parte dos orçamentos que a gente recebe termina com a recomendação de usar um SaaS pronto, porque a operação ainda não justifica código próprio.

Como comparar orçamentos de software na prática

Antes de assinar qualquer contrato, pergunta isso:

1. "Qual é a funcionalidade que vocês estimaram com maior incerteza e por quê?" Resposta boa aponta um risco específico. Resposta ruim diz que está tudo tranquilo.
2. "O que vocês tirariam do escopo se o orçamento fosse 30% menor?" Quem sabe priorizar entendeu o problema. Quem responde "nada" não pensou.
3. "Me mostra um sistema parecido que vocês mantêm em produção há mais de um ano." Não um print, um sistema rodando, com números.
4. "Se eu quiser trocar de fornecedor daqui a dois anos, o que eu levo?" A resposta tem que ser: tudo.
5. "Qual é o custo mensal depois da entrega, no cenário mais provável?" Um número, não "depende".

Depois disso, normalize as propostas: mesmo escopo, mesmas etapas incluídas, mesmo tipo de time. Só então o preço vira comparável. Muitas vezes a diferença real entre a proposta cara e a média cai de duas vezes para 30%, e aí a conversa passa a ser sobre senioridade e risco, não sobre desconto.

Onde a OCA entra nessa conta

Esse é o tipo de projeto que a gente constrói. O sistema de gestão para imobiliárias que operamos em produção nasceu de um pedido parecido: uma operação de locação que rodava em planilha e em três sistemas que não conversavam. A proposta que fizemos tinha lista de funcionalidades por fluxo, uma seção de "fora do escopo" maior do que o cliente esperava, entregas quinzenais e o custo mensal de operação já no papel. O escopo inicial ficou menor do que o cliente pediu, e a primeira versão entrou em uso antes de o projeto acabar.

A gente consegue dar esse tipo de número porque roda os próprios produtos. O Revo App, nossa plataforma de eventos, tem mais de 40 mil usuários e um checkout próprio que converte a 90%. Cada faixa de preço deste artigo vem de projeto que a gente estimou, executou e mantém, não de tabela de terceiro. Você pode ver outros sistemas que construímos em nosso portfólio de projetos.

Time pequeno e sênior: quem estima é quem escreve o código. Isso não é detalhe de marketing. É o que faz a estimativa ser confiável, porque quem vai sofrer com o número errado é a mesma pessoa que o deu.

Próximo passo

Se você está com propostas na mesa agora, passe cada uma pela lista de oito itens acima e anote o que não está respondido. Mande essas perguntas para os fornecedores antes de decidir. Só esse exercício elimina metade das ciladas.

Se ainda não tem proposta, ou quer uma segunda opinião sobre a que recebeu, a gente faz essa leitura com você. Sem compromisso, e com a chance real de a resposta ser "isso aqui não precisa de software sob medida".

Converse com a OCA sobre o seu sistema