# Quanto custa manter um sistema depois de pronto > O custo de um sistema não termina na entrega. Veja o que se paga depois do go-live e como o desenho define essa conta antes da primeira linha de código. - Autor: Marlon Trettin - Publicado: 2026-08-17 · Atualizado: 2026-08-25 - Idioma: pt-BR - Canonical: https://yowpi.com/blog/custo-de-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. ## TL;DR - Em pesquisa da [McKinsey com 50 CIOs](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity) de empresas de serviços financeiros e tecnologia com receita acima de US$ 1 bilhão, de 10% a 20% do orçamento de tecnologia destinado a produtos novos é desviado para resolver problemas de dívida técnica. - No mesmo levantamento, os CIOs estimaram que a dívida técnica equivale a algo entre 20% e 40% do valor de todo o parque tecnológico antes da depreciação, e 60% deles perceberam esse número subir em três anos. - O estudo de [Flyvbjerg e Budzier com 1.471 projetos de TI](https://arxiv.org/pdf/1304.0265) apontou estouro médio de custo de 27%, com um em cada seis projetos estourando 200% em média. - Orce o sistema em três anos, não em uma entrega. O método está na seção "Como orçar três anos, não um projeto". ## 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](https://arxiv.org/pdf/1304.0265) 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](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity), 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](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity) 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](https://www.gartner.com/en/documents/7092135), 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](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity) 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](https://abes.org.br/mercado-de-ti-no-brasil-cresce-185-em-2025-e-pais-segue-lider-na-america-latina/) 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](/cases/colo-saude), 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](/cases/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](/contato) é uma sessão de 30 minutos para olhar onde essa conta está sendo decidida na sua operação.