Quanto custa manter um sistema depois de pronto
Manter um sistema depois de pronto custa em quatro linhas: infraestrutura, correções, mudanças na operação e evolução. Nenhuma delas some com o tempo. O valor exato varia, mas o padrão não. Quanto mais acoplado e menos documentado o sistema, maior a conta anual. E essa conta é decidida no desenho, não na fatura.
Por que o orçamento para no dia da entrega?
Porque a proposta comercial termina ali. Você recebe um escopo, um prazo e um valor. O que acontece no mês seguinte à entrega raramente aparece na mesma planilha, e o efeito é previsível: a empresa aprova o investimento com um número e convive com outro.
A confusão vem de tratar software como obra e não como ativo em operação. Máquina tem plano de manutenção. Veículo tem revisão. Sistema, que muda toda vez que a operação muda, entra no orçamento como se fosse compra única.
O risco de errar essa conta não é teórico. Bent Flyvbjerg e Alexander Budzier analisaram 1.471 projetos de TI e encontraram estouro médio de 27% no custo. O dado mais duro está na cauda: um em cada seis projetos estourou 200% em média e atrasou quase 70%. A média engana; o extremo é que quebra caixa.
O que se paga depois do go-live?
Quatro linhas, e vale separar cada uma no orçamento.
Infraestrutura e licenças é a mais visível. Servidor, banco, armazenamento, envio de e-mail e mensagem, ferramentas de terceiros. Cresce com o uso, o que é justo, desde que você saiba a curva antes de escalar.
Correção é o que ninguém programa e todo mundo paga. Erro em produção, dado inconsistente, integração que parou porque o fornecedor mudou a API. Volume alto de correção nos primeiros meses costuma indicar entrega apressada, não azar.
Mudança na operação é a linha mais subestimada. A empresa contrata um novo tipo de cliente, muda a regra de comissão, entra numa exigência fiscal nova. O sistema precisa acompanhar. Isso não é defeito do software, é a operação viva.
Evolução é o que você quer estar pagando. Relatório novo, automação de uma etapa que ainda é manual, portal para o cliente. Se as três primeiras linhas consomem quase todo o orçamento, a quarta não acontece.
É exatamente aí que a conta aperta. Segundo a McKinsey, de 10% a 20% do orçamento reservado a produtos novos acaba desviado para resolver dívida técnica. O dinheiro do futuro paga o passado. A escala dessas empresas é outra, claro. O mecanismo é o mesmo, e numa operação menor ele aparece mais rápido, porque o orçamento é menor.
Como o desenho define a conta anual?
O custo de manutenção nasce em decisões tomadas antes da primeira linha de código. Três delas pesam mais que todas as outras.
A primeira é acoplamento. Quando a regra de negócio está espalhada por vários pontos do código, qualquer alteração vira caça ao tesouro. Uma mudança de regra de comissão que deveria levar duas horas leva duas semanas, e o teste de tudo que quebrou junto leva mais uma.
A segunda é fronteira de dados. Sistema que não define qual é a fonte da verdade de cada informação gera conciliação eterna. A cada mês alguém compara duas listas para descobrir qual está certa, e esse alguém custa salário.
A terceira é conhecimento concentrado. Sem documentação, sem padrão de código e sem mais de uma pessoa capaz de mexer, o custo de manutenção passa a incluir um risco: a agenda de uma pessoa só. Quando ela sai, você não perde um desenvolvedor, perde o manual.
A McKinsey também dá uma régua útil para decidir quando parar de remendar. Quando a dívida técnica de uma área ultrapassa 50% do valor do ativo de tecnologia, o custo e o risco de manter começam a superar o benefício. O Gartner, no relatório How to Prioritize and Sell Technical Debt Remediation, publicado em 21 de outubro de 2025, registrou que menos de 20% dos líderes de aplicações e engenharia de software se consideram muito eficazes na gestão de dívida técnica, embora 44% das organizações digam que o tema é um dos principais desafios. Quase todo mundo sabe que a conta existe. Poucos a administram.
Um exemplo com números
O cenário abaixo é hipotético, montado para ilustrar a aritmética. Nenhum cliente real está descrito aqui.
Uma distribuidora com faturamento de R$ 400 mil por mês encomenda um sistema de pedidos e comissões por R$ 180 mil, entregue em cinco meses. No primeiro ano depois do go-live, a empresa paga R$ 1.200 por mês de infraestrutura e serviços, contrata 20 horas mensais de correção e ajuste a R$ 200 a hora, e faz duas mudanças de regra por semestre a R$ 11 mil cada.
A conta anual fica em R$ 14.400 de infraestrutura, R$ 48 mil de horas e R$ 44 mil de mudanças. Total de R$ 106.400, ou 59% do valor da construção, no primeiro ano. Evolução: zero. Não sobrou orçamento para ela, e é exatamente esse o sintoma. Se a empresa tivesse orçado só a obra, o segundo ano chegaria como surpresa.
Agora mude uma variável. Suponha que a regra de comissão esteja isolada em um único ponto do sistema, com teste automatizado. As duas mudanças de semestre caem de R$ 11 mil para R$ 3 mil cada. A conta anual vai para R$ 74.400. A diferença de R$ 32 mil por ano não veio de negociar hora mais barata. Veio de uma decisão de desenho tomada antes de começar.
Como orçar três anos, não um projeto
Comece pedindo ao fornecedor, ainda na proposta, uma estimativa das quatro linhas para os 24 meses seguintes à entrega. Quem projeta sistemas com frequência sabe responder. Quem trava na pergunta está vendendo obra.
Depois, escreva no contrato quem responde por correção de defeito e em que prazo, com uma janela clara de garantia. Correção de erro de entrega e mudança pedida pela empresa são coisas diferentes e precisam ter preços diferentes.
Terceiro, exija a saída. Código em repositório seu, credenciais de infraestrutura no seu nome, dados exportáveis em formato aberto, documentação mínima de arquitetura e de decisões. Sistema do qual você não consegue sair tem custo de manutenção definido por outra pessoa.
Por último, reserve uma fatia fixa e previsível do orçamento anual para reduzir dívida técnica, proporcional à idade do sistema. A McKinsey recomenda o oposto do mutirão: pagamento contínuo ao longo do tempo, porque megaprojeto de modernização concentra risco de execução. É a lógica de qualquer manutenção preventiva.
Esse rigor vale ainda mais agora. O estudo ABES e IDC mostra que o mercado brasileiro de TI cresceu 18,5% em 2025, para US$ 67,8 bilhões, mas projeta apenas 5,3% para 2026, com investimentos mais seletivos e orientados a custo e impacto no negócio. Quem entra nesse ciclo sem saber o custo de operar o que já tem escolhe no escuro.
Dois casos nossos mostram os dois lados dessa conta. Na Colo Saúde, a plataforma foi recebida já em operação e o trabalho começou pelo custo de mantê-la, com redução de 60% no consumo da plataforma no-code em que ela rodava, e a queda correspondente no plano mensal, antes de qualquer funcionalidade nova. Na UniTrust, o sistema nasceu em no-code em 2022 e, quatro anos depois, iniciou a migração para arquitetura proprietária, conduzida pela mesma equipe. Nos dois, a decisão foi sobre o que custaria operar depois, não sobre o que custaria construir.
Perguntas frequentes
Existe uma porcentagem padrão de manutenção anual sobre o valor do projeto?
Circulam percentuais de mercado, mas nenhum deles resiste ao teste do caso concreto: complexidade, número de integrações e ritmo de mudança da operação alteram demais o resultado. Estime as quatro linhas com o seu fornecedor, usando o seu sistema como base, e revise a cada seis meses.
Software pronto de prateleira resolve esse problema?
Muda a natureza da conta, não a existência dela. Você troca correção e evolução por mensalidade, customização, integração e dependência de um roteiro de produto que não é seu. A pergunta continua a mesma nos dois casos: quanto custa operar isso por três anos.
Meu sistema atual já custa caro para mudar. Vale reescrever?
Nem sempre. Antes de decidir, meça: quanto tempo leva hoje uma mudança típica, quantas pessoas conseguem fazê-la e qual fatia do orçamento vai para correção. Se a resposta indicar que manter já consome mais da metade do que o ativo vale para o negócio, a discussão deixa de ser técnica e vira decisão de investimento.
A conta é decidida no desenho
Manutenção cara raramente é problema de tecnologia. É o preço mensal de uma decisão de arquitetura tomada uma vez, antes da primeira linha de código.
Se você está prestes a aprovar um sistema novo, ou já convive com um cuja manutenção cresce todo trimestre, vale meia hora de conversa. Nosso Diagnóstico de Arquitetura Operacional é uma sessão de 30 minutos para olhar onde essa conta está sendo decidida na sua operação.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem compromisso.
Agendar diagnóstico