“Quanto custa fazer um aplicativo?” não se responde com um número, e não é porque o fornecedor está fugindo. A razão é mais profunda: o preço é definido pela quantidade de decisões, não pela quantidade de telas.
Dois aplicativos com o mesmo número de telas podem custar várias vezes mais um que o outro, dependendo de o fluxo de pagamento já estar padronizado, de haver migração de dados de um sistema antigo e de quantas exceções antes resolvidas por uma pessoa agora precisam virar regra escrita.
Seis componentes que formam o preço
| Componente | O que abrange | Por que é subestimado |
|---|---|---|
| Análise e mapeamento | Traduzir o processo em especificação | Parece só reunião, mas define todo o custo seguinte |
| Design de interface | Fluxo de telas, layout e componentes | Refazer design é muito mais barato que refazer código |
| Desenvolvimento | Escrever as funções no cliente e no servidor | A parte mais visível, raramente a mais cara |
| Integrações | Pagamento, transporte, contabilidade, sistemas antigos | Costuma aparecer no meio e altera o orçamento |
| Testes e correções | Achar e fechar falhas antes de publicar | Cortado por prazo e depois pago em dobro |
| Migração e treinamento | Levar dados antigos e preparar a equipe | O mais esquecido, embora decida a adoção |
Uma frase que economiza muito dinheiro: Peça a proposta detalhada pelos componentes acima. Quem consegue detalhar normalmente pensou no trabalho; quem não consegue está chutando — e esse chute vira aditivo no seu orçamento.
Por que propostas variam de três a dez vezes
As diferenças grandes quase sempre vêm de quatro fontes, e quase nunca de simplesmente “um é caro e o outro é barato”.
- Escopos silenciosamente diferentes. Um inclui testes, migração e treinamento; o outro contou só o desenvolvimento.
- Grau de personalização. Construir do zero é outro trabalho, diferente de adaptar algo existente.
- Quem executa. Times sêniores custam mais por hora e muitas vezes menos por entrega, porque há menos retrabalho.
- Modelo de propriedade. O preço muda se você pedir a propriedade plena do código em vez de direito de uso.
Três caminhos, três estruturas de custo
Antes de pedir propostas, decida qual caminho você realmente precisa. Muito orçamento evapora porque a empresa escolhe o caminho mais caro para uma necessidade que era comum.
| Caminho | Quando faz sentido | Estrutura de custo |
|---|---|---|
| Comprar sistema pronto | Necessidade padrão e prazo curto | Pagamento único, depois servidor e manutenção |
| Semi-personalizado | O pronto quase serve, mas precisa de ajuste | Preço do sistema mais adaptação |
| Sob medida completo | Seu processo é peculiar e é vantagem competitiva | Mais caro na largada, mais flexível no longo prazo |
Como âncora concreta, sistemas prontos já testados variam muito conforme o escopo. No próprio catálogo da MDH, plugins e sistemas leves ficam entre centenas de milhares e um milhão de rupias; uma plataforma de CRM omnichannel pronta para produção fica na casa de sete milhões e meio; um aplicativo com marca própria, em torno de dez milhões; e um PDV completo com módulo de RH, na casa de cinquenta milhões, por ter escopo bem maior.
Esses números servem de âncora. Se a proposta sob medida ficar muito acima do preço de um sistema pronto que já atende, pergunte exatamente o que o pronto não consegue fazer.
Os custos que aparecem depois da entrega
É a parte mais ausente dos orçamentos e a razão de tantos sistemas ficarem abandonados um ano depois.
Regra simples: Orce manutenção anual como percentual fixo do valor do projeto, defina o escopo em detalhe e estabeleça tempo de resposta a incidentes. Sistema sem verba de manutenção é sistema esperando ser abandonado.
Como reduzir custo sem reduzir resultado
- Corte funções, não qualidade. Entregar poucas funções realmente usadas vale mais que muitas pela metade.
- Organize o processo antes de construir. Cada exceção eliminada no papel é custo que não nasce.
- Use sistemas prontos no que não é seu diferencial. Nenhum negócio venceu por construir o próprio módulo de ponto.
- Pague por etapas atreladas a marcos verificáveis, não a datas.
- Peça um teste com dados reais antes do contrato grande. Isso revela problemas enquanto consertar ainda é barato.
Perguntas Frequentes
A equipe da MDH mapeia o processo primeiro, mostra o que um sistema pronto já resolve e o que realmente merece ser feito sob medida. Consulta inicial gratuita.
Falar sobre seu projeto
