Por que dois projetos de software sob medida quase nunca custam o mesmo

Um CRM que parecia simples até a migração da base

O pedido chegou descrito em uma linha: cadastro de cliente, contrato por veículo, cobrança mensal. Um CRM para uma empresa de rastreamento veicular, aparentemente sem nada de excepcional. A complexidade apareceu quando ficou claro que a base existente vivia em planilha, sem histórico de inadimplência, e que a virada precisava trazer os 1.357 contratos ativos para o sistema novo sem interromper a cobrança de nenhum deles. Nenhuma dessas exigências está contida na frase "sistema de CRM com cobrança recorrente", que é como a maior parte dos pedidos de orçamento chega na primeira reunião.

Daí a resposta desconfortável que damos quando alguém pergunta quanto custa um sistema sob medida. O preço acompanha o número de decisões que precisam ser tomadas antes da primeira linha de código, e a tecnologia escolhida para escrevê-lo influencia pouco esse número. Dois projetos descritos com as mesmas palavras podem diferir por um fator considerável quando um deles integra com um sistema legado sem documentação e o outro começa em base limpa.

O que move o preço de um projeto sob medida

Quantas entidades o sistema modela, quantos perfis de acesso existem, quantos sistemas externos precisam ser consultados sem quebrar o que já funciona: são essas contagens que empurram o orçamento para cima ou para baixo, muito mais do que a linguagem ou o framework anunciados na proposta.

No CRM de rastreamento, cada peça isolada seria um projeto pequeno. Autenticação com TOTP, controle de acesso por papel e cobrança recorrente via Stripe são problemas conhecidos, com bibliotecas maduras e documentação abundante. Juntas, somadas à exigência de manter histórico auditável de cada alteração e de conciliar recebível no mesmo sistema em que o cliente contrata pelo site, formaram um trabalho cuja dificuldade estava na costura entre as partes. Orçamento malfeito subestima justamente essa costura, porque ela não aparece em nenhuma lista de funcionalidades.

Migração de sistema legado obedece à mesma lógica, como no case de migração de ERP legado para AWS: num ERP de financeiro, fiscal e folha migrado para AWS EC2, o código de aplicação não mudou uma linha sequer. O custo estava em preservar a integração com o diretório corporativo depois da virada, em estabelecer a conexão VPN Site-to-Site entre a rede local e o novo ambiente e em executar tudo dentro de uma janela de manutenção que não podia atropelar o fechamento fiscal do mês. Uma proposta que lê o pedido como "migrar servidor para a nuvem" chega a um número que não sobrevive ao primeiro ensaio de virada.

Quando o produto de prateleira resolve melhor

Construir sob medida, o que fazemos na frente de Desenvolvimento Full-Stack, se justifica quando o processo de negócio em questão é o diferencial competitivo da empresa, ou quando a combinação específica de exigências não existe montada em nenhum produto disponível. Para um formulário que qualquer ferramenta genérica resolve, a resposta correta na primeira reunião é dizer isso em voz alta.

Hora sem teto e a perda de controle do escopo

Cobrança por hora parece justa até o projeto esbarrar na primeira integração malformada. Um fornecedor que não descobre, ainda na fase de orçamento, que o sistema legado do cliente não expõe API e exige leitura direta do banco vai gastar semanas em descoberta que deveriam ter sido um diagnóstico pago à parte, antes de o contrato de desenvolvimento entrar em vigor. O relógio corre, a fatura cresce e, no meio do projeto, ninguém consegue mais separar atraso de execução de escopo que mudou sem que a mudança fosse formalizada por alguém.

O modelo continua adequado para manutenção contínua e para trabalho evolutivo sem escopo fechado, situações em que não existe entrega única contra a qual medir o andamento. Para construção do zero, ele tira de um cliente sem equipe técnica própria a capacidade de auditar o meio do caminho e transfere o risco inteiro para quem paga a fatura.

Conformidade e disponibilidade são custos recorrentes

Dois fatores entram tarde nos orçamentos e raramente saem baratos quando entram. O primeiro é exigência regulatória: sistema que trata dado pessoal sensível, saúde entre eles, ou dado financeiro sob regulação setorial precisa de decisão de schema, política de log e controle de acesso definidos na arquitetura inicial, porque corrigir isso com o sistema em produção envolve migração de dado e revisão de relatório que já dependiam do formato anterior.

O segundo é disponibilidade. Operação contínua durante horário comercial, sem tolerância a interrupção, exige redundância entre zonas de disponibilidade, monitoramento com alerta calibrado e alguém de plantão para responder fora do expediente. Esse custo é mensal e acompanha o sistema por toda a vida útil dele, enquanto o desenvolvimento inicial é pago uma vez. Proposta que apresenta apenas o segundo número descreve metade da despesa e cria uma surpresa agendada para o trimestre seguinte ao lançamento.

O que precisa estar por escrito antes da assinatura

Em contrato de escopo fechado, escopo detalhado o suficiente para que uma mudança de requisito seja identificável como tal, cronograma com marcos verificáveis em lugar de uma data única no fim, e retorno esperado expresso em termos de negócio, seja redução de custo operacional, seja receita nova habilitada pelo sistema. Quando essa última conta não fecha, o fornecedor deveria dizer isso antes de começar o trabalho.

Falta ainda o item que mais gera atrito em projeto longo, e que quase nunca aparece nas propostas: o procedimento de mudança de escopo. Quem aprova o replanejamento, como prazo e custo adicional são recalculados e a partir de que tamanho um pedido informal vira adendo formal. Sem isso escrito, mudanças pequenas são absorvidas pela equipe sem impacto declarado no cronograma até que o acúmulo apareça de uma vez, na forma de um atraso que ninguém consegue atribuir a nenhuma decisão específica, porque de fato não houve nenhuma.