Como estimamos o custo de software: a metodologia da Bradata

A maioria das estimativas de software está errada. De propósito ou por ignorância.

Desenvolvedores subestimam esforço. Gerentes de projeto subestimam complexidade. Clientes subestimam a quantidade de requisitos que vão surgir depois da primeira reunião. O Standish Group mostra que apenas 31% dos projetos de software terminam dentro do prazo e orçamento originais. Não é um problema novo.

Na Bradata, construímos uma metodologia de estimativa baseada em scoring de complexidade. Não é perfeita. Nenhuma estimativa é. Mas ela reduz a margem de erro porque substitui opinião por critérios mensuráveis.

O sistema de scoring de complexidade

Cada projeto passa por uma avaliação em seis categorias. Cada categoria recebe uma nota de 1 a 5. A soma dessas notas gera um score total que determina a faixa de complexidade do projeto.

Categoria	Score 1 (baixo)	Score 3 (médio)	Score 5 (alto)
Integrações	Nenhuma API externa	2 a 4 APIs, protocolos padronizados	5+ APIs, legado, protocolos proprietários
Autenticação e permissões	Login simples	SSO, roles básicos	Multi-tenant, RBAC granular, audit trail
Volume de dados	Milhares de registros	Centenas de milhares	Milhões, com requisitos de performance
Requisitos regulatórios	Nenhum específico	LGPD básica	LGPD completa, certificações setoriais, governo
Lógica de negócio	CRUD com validações simples	Regras condicionais, workflows	Cálculos financeiros, regras tributárias, motor de regras
Tempo real	Apenas requisições síncronas	Notificações push	WebSocket, streaming de dados, processamento assíncrono pesado

Um CRUD administrativo simples pode somar 8 pontos. Um SaaS B2B com integrações e compliance chega a 22. Um sistema para o setor público com integrações legadas e requisitos do TCU pode bater 28.

Esses números não viram preço diretamente. Eles determinam qual perfil de equipe o projeto precisa e quanto tempo cada fase vai consumir.

Composição de equipe por faixa de complexidade

O custo de um projeto não depende só de quantas horas leva. Depende de quem precisa estar envolvido.

Score 6 a 12 (complexidade baixa). Um full-stack sênior com apoio de designer resolve. Deploy em PaaS como Railway ou Render. Equipe: 2 a 3 pessoas.

Score 13 a 20 (complexidade média). Separação entre backend e frontend. Tech lead para decisões arquiteturais. QA dedicado porque cenários de teste crescem exponencialmente com integrações. Equipe: 4 a 6 pessoas.

Score 21 a 30 (complexidade alta). Arquiteto de solução desde o dia zero. DevOps dedicado. Analista de segurança para compliance. Product owner para gerenciar escopo. Possivelmente DBA. Equipe: 6 a 10 pessoas.

Colocar uma equipe de 3 num projeto de score 25 não economiza dinheiro. Gera retrabalho, atrasos e dívida técnica que custa mais para resolver depois.

Fatores de infraestrutura

O terceiro pilar da estimativa são os custos de infraestrutura, que muitos clientes descobrem só na hora do deploy.

Cloud vs. on-premise. A maioria dos projetos vai para AWS, Azure ou GCP. Mas projetos governamentais e de saúde às vezes exigem infraestrutura privada ou nuvem soberana. Isso multiplica o custo operacional mensal em 3x a 5x.

Requisitos de compliance. LGPD exige criptografia em repouso e em trânsito, logs de acesso, anonimização. Para saúde, soma-se SBIS. Para governo, SISP. Cada camada adiciona custo de desenvolvimento e operação.

Escala esperada. Um sistema para 50 usuários simultâneos roda num servidor de R$ 200/mês. Para 5.000 usuários simultâneos, precisa de auto-scaling, CDN, cache distribuído, banco replicado. A conta sobe para R$ 8.000 ou mais.

Por que preço fixo é uma armadilha

Escopo fechado com preço fixo parece seguro para o cliente. Na prática, acontece uma de duas coisas.

Cenário 1: o fornecedor subestimou o esforço e corta qualidade para não ter prejuízo. Menos testes, deploy manual, features "simplificadas" sem avisar. Funciona na demo, quebra em produção.

Cenário 2: o fornecedor superestimou para se proteger e o cliente paga 40% a mais. Ou acertou o escopo inicial, mas toda mudança vira "aditivo contratual" que infla o custo final.

Software não é construção civil. Não existe planta baixa definitiva antes de começar a construir. Requisitos mudam conforme o sistema toma forma.

A alternativa: estimativa por faixa com checkpoints

Na Bradata, trabalhamos com estimativas em faixa. Em vez de "o projeto custa R$ 280.000", dizemos "a faixa é de R$ 240.000 a R$ 320.000, com revisão a cada sprint".

Cada checkpoint (a cada 2 semanas) reavalia o escopo restante. Estimativa cai se o projeto ficou mais simples. Se surgiram requisitos novos, o cliente decide se absorve o custo ou corta funcionalidade.

Para projetos de alta incerteza, usamos time and materials com cap. O cliente define um teto. A equipe entrega por prioridade até o teto. Se o orçamento acaba antes, o que foi entregue está em produção e funcionando.

Exemplo prático: SaaS B2B de gestão de contratos

Vamos a um caso concreto. Um cliente quer um SaaS para gestão de contratos B2B com estas features: cadastro de contratos e aditivos, alertas de vencimento, assinatura digital via integração com DocuSign, dashboard com métricas, multi-tenant para revenda.

Scoring:

• Integrações: 3 (DocuSign, gateway de e-mail, API de billing)
• Autenticação: 4 (multi-tenant com RBAC)
• Volume de dados: 2 (milhares de contratos, não milhões)
• Regulatório: 3 (LGPD com dados sensíveis contratuais)
• Lógica de negócio: 3 (workflows de aprovação, cálculo de reajustes)
• Tempo real: 2 (notificações, sem streaming)

Score total: 17. Complexidade média.

Equipe sugerida: 1 tech lead/backend, 1 frontend, 1 designer (parcial), 1 QA, 1 product owner (parcial). Total: ~4 pessoas equivalentes full-time.

Estimativa de prazo: 4 a 6 meses para MVP. Mais 2 a 3 meses para features completas.

Faixa de investimento: R$ 180.000 a R$ 260.000 para o desenvolvimento. Infraestrutura mensal estimada em R$ 1.500 a R$ 3.000 dependendo do número de tenants.

Os custos que ninguém lembra de incluir

Quase toda proposta comercial esquece pelo menos três destes itens:

• Ambientes de staging e homologação. Produção não é o único servidor. Precisa de pelo menos mais dois ambientes. Custo extra de 30% a 50% em infraestrutura.
• CI/CD e monitoramento. Pipeline de deploy automatizado, alertas de erro, métricas de performance. Configurar isso consome de 40 a 80 horas de DevOps.
• Auditoria de segurança. Pentest antes do go-live. Um pentest sério para uma aplicação web custa entre R$ 15.000 e R$ 40.000.
• Documentação técnica. API docs, runbooks, documentação de arquitetura. O custo de não ter documentação aparece na primeira manutenção.
• Treinamento. Sessões, material de apoio, vídeos. Considere de 20 a 40 horas para um sistema de complexidade média.

Somar esses itens pode adicionar 15% a 25% ao custo total do projeto. Quem não inclui na proposta vai cobrar depois ou simplesmente não vai entregar.

Conclusão direta

Estimativa de software não é adivinhação. É um processo com critérios, pesos e revisões constantes. Nenhuma metodologia elimina incerteza, mas uma boa metodologia transforma incerteza em faixas gerenciáveis com decisões claras a cada etapa.

Se você está avaliando o custo de um projeto, descreva o escopo para a Bradata e receba uma estimativa que aplica exatamente a lógica descrita aqui. E se o número levantar mais perguntas do que respostas, isso provavelmente significa que o projeto precisa de uma discovery antes de uma proposta.