Quase todo orçamento de software para no dia do lançamento. Aprova-se o valor para "fazer o sistema", comemora-se quando ele entra no ar, e a planilha considera o projeto encerrado. Só que software não funciona assim. O lançamento não é a linha de chegada — é a linha de partida.
Um sistema em produção é um organismo vivo. Ele depende de bibliotecas que se atualizam, de navegadores que mudam, de servidores que evoluem e de usuários que usam o produto de jeitos que você não previu. Tudo isso gera trabalho. Trabalho que alguém precisa fazer, e que alguém precisa pagar.
O que é, de fato, manutenção
Manutenção não é um item só. São pelo menos três tipos de trabalho diferentes, e confundi-los é o primeiro erro de quem orça:
- Corretiva: consertar o que quebrou. Bugs que escaparam dos testes, comportamentos inesperados, casos de uso que ninguém imaginou. Por mais cuidadoso que seja o desenvolvimento, isso sempre existe.
- Evolutiva: ajustar o sistema à realidade. Uma regra de negócio que mudou, um relatório novo que a diretoria pediu, um fluxo que se mostrou confuso na prática. O produto melhora porque o uso real ensina coisas que nenhum planejamento ensina.
- Atualizações e segurança: manter a base saudável. Dependências desatualizadas viram brechas de segurança. Versões antigas de linguagem deixam de receber suporte. Isso é trabalho invisível para o usuário, mas inadiável para quem cuida do sistema.
Os três acontecem. A diferença entre uma empresa que dorme tranquila e outra que vive apagando incêndio é só uma: a primeira sabia que isso ia acontecer e reservou orçamento.
Por que ignorar isso sai caro
Software sem manutenção não fica parado no tempo — ele apodrece. A cada mês adiado, a dívida técnica cresce e os juros aumentam.
Manutenção não é gasto extra. É o custo de manter funcionando aquilo em que você já investiu.
Um exemplo concreto. Uma dependência crítica lança uma correção de segurança. Se o sistema está em dia, a atualização é rotina — algumas horas de trabalho. Se ele ficou dois anos sem cuidado, essa mesma atualização exige migrar várias outras bibliotecas que ficaram para trás, ajustar código que mudou de assinatura e testar o sistema inteiro de novo. O que custaria pouco virou um projeto.
# Em um sistema cuidado regularmente, isso é um exercício de minutos
npm outdated
npm audit
Esse comando simples revela o tamanho do problema antes que ele vire crise. Rodar isso uma vez por mês é barato. Descobrir tudo de uma vez, dois anos depois, não é.
Quanto reservar
Não existe número mágico, mas existe uma faixa razoável: a manutenção anual costuma ficar entre 15% e 25% do custo de construção do sistema. Um produto que custou para ser feito vai custar, todo ano, uma fração disso para continuar saudável.
Esse valor varia com alguns fatores:
- Tamanho e complexidade. Mais funcionalidades, mais superfície para manter.
- Número de integrações. Cada sistema externo conectado é um ponto que pode mudar sem aviso.
- Ritmo do negócio. Uma empresa que cresce rápido pede mais evolução do que correção.
- Qualidade da construção inicial. Código bem feito é mais barato de manter — outro motivo para não cortar qualidade no começo.
O ponto não é o percentual exato. É colocar a linha na planilha. Um orçamento que ignora manutenção não economizou dinheiro — só escondeu uma despesa que vai aparecer do jeito mais caro possível, geralmente no pior momento.
Manutenção é continuidade, não conserto
Encarar manutenção como "consertar defeito" é o enquadramento errado. O enquadramento certo é continuidade: o sistema é um ativo da empresa, e ativos precisam de cuidado para não virar passivo. Um carro precisa de revisão. Um imóvel precisa de reforma. Software não é diferente.
Na ChavesTech, a gente trata manutenção como parte do projeto desde a primeira conversa — não como surpresa depois do lançamento. E como você fala direto com quem desenvolveu o sistema, quem cuida dele já conhece cada decisão tomada. Não há repasse de conhecimento se perdendo no caminho: a continuidade é real, e o seu investimento continua de pé.