Quanto custa desenvolver um software sob medida — e por que ninguém te dá o preço na primeira conversa

"Quanto custa fazer um sistema?" é a primeira pergunta de quase toda conversa — e a única que nenhum fornecedor sério responde de imediato. Não por falta de transparência: é que a pergunta, do jeito que foi feita, equivale a perguntar quanto custa construir uma casa sem dizer o tamanho do terreno.

O que dá para explicar com precisão é a estrutura de custo. Quem entende como o preço se forma consegue avaliar propostas, negociar escopo e prever o gasto dos próximos anos. É disso que este texto trata.

O preço é horas de engenharia, não funcionalidades

Software não tem matéria-prima. O custo de um projeto é, essencialmente, o tempo de pessoas qualificadas multiplicado pelo valor da hora dessas pessoas. Tudo o mais — ferramentas, infraestrutura, licenças — costuma ser marginal na fase de construção.

Isso muda a forma de ler um orçamento. Duas propostas com a mesma lista de telas podem ter preços muito diferentes porque uma assume 300 horas e a outra assume 900. Se ninguém explicita a estimativa de esforço, você não está comparando propostas: está comparando chutes.

Ordem de grandeza, em esforço

• MVP bem delimitado — um fluxo principal, um perfil de usuário, poucas integrações: normalmente algo entre 400 e 900 horas de engenharia.
• Sistema de operação completo — múltiplos perfis, permissões, relatórios, duas ou três integrações reais: a faixa costuma ficar entre 1.200 e 3.000 horas.
• Plataforma multiempresa — isolamento de dados por cliente, cobrança, painel administrativo, auditoria: a partir de 3.000 horas, e cresce com o número de mercados atendidos.

Multiplique pela hora praticada pelo fornecedor e você tem a ordem de grandeza. A hora varia muito conforme senioridade da equipe, região e nível de responsabilidade assumido pelo contrato — e é justamente aí que a comparação fica interessante, porque hora barata com retrabalho sai mais cara que hora cara com acerto de primeira.

Os sete fatores que mais mexem no preço

1. Quantidade de perfis de usuário. Cada perfil traz regras de permissão, telas próprias e testes próprios. Dois perfis não custam o dobro de um — custam mais que o dobro.
2. Integrações com sistemas de terceiros. É o item mais subestimado de qualquer orçamento. Uma API bem documentada é previsível; um ERP legado sem documentação pode consumir sozinho um quarto do projeto.
3. Migração de dados. Trazer a base antiga quase nunca é "importar uma planilha". É tratar duplicidade, campo vazio, formato inconsistente e regra que mudou no meio do caminho.
4. Regras de negócio com exceção. "Sempre funciona assim, menos quando o cliente é X" é a frase mais cara do discovery. Cada exceção é um caminho a mais para construir e testar.
5. Nível de exigência de disponibilidade. Um sistema interno que pode ficar dez minutos fora do ar custa bem menos que um que não pode parar nunca.
6. Volume e desempenho. Mil registros e dez milhões de registros exigem arquiteturas diferentes. Se o volume não foi dito, ele não foi orçado.
7. Design sob medida. Interface desenhada a partir das tarefas reais do usuário custa mais que tela padrão — e economiza em treinamento, suporte e adoção.

Três modelos de contrato e o risco de cada um

Escopo fechado

Preço e entrega definidos antes de começar. Dá previsibilidade orçamentária, mas só funciona quando o escopo está de fato fechado. Como o fornecedor assume o risco da estimativa, o preço embute uma gordura — e toda mudança vira aditivo. É o modelo que mais gera atrito quando o levantamento foi superficial.

Tempo e materiais

Você paga pelas horas efetivamente trabalhadas. Flexível e honesto, exige acompanhamento próximo e uma relação de confiança. Sem teto e sem prioridade clara, é o modelo que mais estoura.

Squad dedicada

Um time alocado por período, com prioridade definida por você a cada ciclo. Faz sentido quando o software é contínuo, não um projeto com fim. Custo mensal previsível, escopo variável.

O custo depois do go-live

Aqui está o erro mais caro de todos: tratar software como obra, com data de entrega e fim. Software é operação. Depois que entra no ar, ele consome orçamento todo mês.

• Infraestrutura: servidores, banco de dados, armazenamento, backup, monitoramento. Cresce com o uso.
• Manutenção evolutiva: a regra de negócio muda, a lei muda, o parceiro muda a API. Como ordem de grandeza, planeje algo entre 15% e 25% do valor do desenvolvimento por ano.
• Correções e suporte: mesmo com boa cobertura de testes, produção revela o que homologação não revelou.

Uma proposta que não menciona nenhum desses três itens não é mais barata. É incompleta.

Como reduzir o custo sem quebrar o projeto

• Corte escopo, não qualidade. Entregar menos funcionalidades bem-feitas é sempre melhor que entregar tudo pela metade. Teste, documentação e segurança não são itens opcionais de orçamento.
• Comece pelo fluxo que dói mais. Um módulo em produção gerando valor financia e direciona o próximo muito melhor que um plano de dois anos no papel.
• Aceite o processo padrão onde ele serve. Customizar o que não é diferencial é gastar dinheiro para ficar igual.
• Invista no levantamento. É contraintuitivo, mas o discovery é a parte do projeto com maior retorno: cada suposição eliminada antes da primeira linha de código economiza várias horas depois.

O que pedir em qualquer proposta

Antes de comparar valores, exija que toda proposta traga: estimativa de esforço por etapa, premissas assumidas, o que está explicitamente fora do escopo, quem é dono do código, como funciona a garantia e qual o custo mensal estimado de operação. Com esses seis itens na mesa, a comparação deixa de ser entre números soltos.

Na Sixtec, o orçamento nasce do levantamento da operação, não de uma tabela — é a primeira etapa do nosso processo. Se quiser uma estimativa para o seu caso, conte o desafio da sua operação.