Dívida técnica: o que é, quanto custa para o seu negócio e quando vale a pena pagar (os sinais que você enxerga sem ser técnico)

O sistema funciona. Foi entregue há dois ou três anos, a operação roda em cima dele e ninguém reclama todo dia. Mas toda vez que você pede uma mudança pequena, a resposta vem em semanas. Um campo novo no cadastro virou um orçamento de quinze dias. A correção de um bug no relatório quebrou a emissão de nota fiscal. E existe uma pessoa, só uma, que sabe mexer na parte do financeiro. Se ela tira férias, a fila espera.

Se você reconhece dois ou três desses sintomas, o seu sistema tem dívida técnica. O nome é técnico, mas o efeito é financeiro: cada mudança custa mais do que deveria, e o custo cresce com o tempo. Este artigo explica o que ela é, como medir quanto está custando por mês e como decidir, com a conta na mão, se vale a pena pagar agora, conviver com ela ou reescrever.

O que é dívida técnica, explicado para quem paga a conta

Dívida técnica é toda decisão de atalho tomada no desenvolvimento que economiza tempo hoje e cobra juros depois. A comparação com empréstimo é exata: o time pegou um adiantamento de prazo, e você paga com horas extras em cada mudança futura.

Alguns atalhos que aparecem em quase todo sistema que a gente herda:

• Uma regra de negócio copiada em quatro lugares diferentes em vez de escrita uma vez. Quando ela muda, alguém precisa lembrar dos quatro.
• Um sistema sem testes automatizados. Cada publicação de versão é uma aposta, e alguém testa na mão o que dá tempo.
• Uma biblioteca ou framework parado numa versão de 2020, porque atualizar quebraria coisas e ninguém quis pagar para descobrir quais.
• Integrações resolvidas com planilha exportada e importada à mão, porque a API ficou para depois.
• Ambiente de teste inexistente. A mudança vai direto para produção, e o cliente é quem descobre o erro.

Um ponto importante: nem toda dívida é erro. Lançar um MVP em oito semanas com atalhos conscientes é uma decisão de negócio correta na maioria dos casos. O problema não é ter dívida. O problema é não saber que ela existe, não saber quanto custa e nunca ter um plano para pagar.

Por que a dívida técnica acontece (e por que raramente é culpa de uma pessoa)

Quem já passou por um projeto travado sabe do que estou falando: a tentação é procurar o culpado. Na prática, a dívida vem de causas estruturais, e três delas se repetem.

Prazo decidido antes do escopo

Quando a data de entrega é fixada antes de alguém entender o tamanho do trabalho, a única variável que sobra é a qualidade. O time corta testes, pula a documentação e resolve na hora. Isso não aparece na entrega. Aparece seis meses depois.

Rotatividade sem transferência de conhecimento

O dev que construiu o módulo saiu, o fornecedor trocou de equipe, o freelancer sumiu. Quem chega depois não entende as decisões e prefere contornar o código antigo a mexer nele. Cada contorno é uma camada nova de dívida em cima da anterior.

Manutenção tratada como custo, não como investimento

O orçamento cobre funcionalidades novas porque elas são visíveis. Atualizar dependências, reescrever um módulo frágil ou criar testes não gera tela nova, então fica sempre para o próximo trimestre. Depois de dois anos de próximos trimestres, o sistema está onde você o encontrou hoje.

Quanto custa a dívida técnica: a conta em horas e reais

O barato que sai caro aqui é o seguinte: a dívida não cobra uma parcela grande. Ela cobra um pouco em cada mudança, e por isso ninguém percebe até somar. A conta que uso com clientes tem três partes.

1. O juro em cada mudança

Pegue uma alteração típica do seu sistema e compare quanto ela leva hoje com quanto levaria em um código saudável. Uma proporção que a gente encontra com frequência em sistemas herdados: a mudança que deveria levar 4 horas leva 12, porque o dev precisa entender código sem documentação, alterar em vários lugares e testar tudo na mão.

Nesse exemplo, a dívida custa cerca de R$ 8.600 por mês só em horas de desenvolvimento. Em um ano, passa de R$ 100 mil. É mais do que a maioria das reformas de módulo custaria. O valor da hora varia de R$ 120 a R$ 250 conforme senioridade e região, e a proporção de horas varia de sistema para sistema, mas a estrutura da conta é sempre essa.

2. O custo dos incidentes

Sistema com dívida quebra mais. Some as horas de correção urgente, o tempo da equipe operacional parada e o que se perde com o cliente. Um checkout fora do ar por duas horas em dia de pico tem preço. Um fechamento de mês atrasado por três dias também. Esses números variam demais por negócio para eu dar uma faixa geral, mas você consegue estimar o seu olhando os últimos seis meses.

3. O custo de oportunidade

É o mais difícil de medir e o mais caro. É a integração com o ERP que ficou para depois porque o sistema não aguenta, a funcionalidade que o concorrente lançou e você não conseguiu, o aplicativo que não sai porque o backend não tem uma API decente. Quando a dívida começa a bloquear decisão de negócio, ela deixou de ser um problema técnico.

Pagar, conviver ou reescrever: as opções na mesa

Não existe resposta única, mas existe conta certa. As opções reais são quatro, e cada uma faz sentido em um momento.

Conviver com a dívida

Faz sentido quando o sistema muda pouco. Se você faz duas alterações por ano em um módulo, o juro é baixo e pagar a dívida não compensa. Muita empresa gasta dinheiro reformando código em que ninguém vai mexer. A pergunta certa é a frequência de mudança, não a idade do código.

Pagar aos poucos

É o caminho padrão para sistemas em uso ativo. Reserva-se uma fatia fixa do esforço mensal, algo entre 15% e 25%, para melhorar o que está no caminho das próximas funcionalidades. Não se reforma o sistema inteiro: reforma-se o módulo que vai ser mexido. Em números: em um contrato de manutenção de R$ 6 mil por mês, entre R$ 1.000 e R$ 1.500 vão para reduzir dívida. Em seis a doze meses, os módulos mais usados ficam saudáveis e o custo por mudança cai.

Reescrever um módulo

Quando um pedaço específico concentra a dor, isolar e reescrever só ele costuma levar de 2 a 6 semanas e custar entre R$ 15 mil e R$ 60 mil, dependendo da complexidade e das integrações. O resto do sistema continua rodando. Esse é o meio-termo que mais resolve e o que a gente mais recomenda.

Reescrever tudo

É a opção mais cara e mais arriscada. Um sistema de porte médio, com integrações e regras de negócio acumuladas em anos, leva de 4 a 9 meses e custa de R$ 150 mil a R$ 500 mil para ser reescrito. Durante esse tempo, o sistema antigo precisa continuar funcionando e recebendo correções. Só compensa quando a base tecnológica está morta (linguagem ou plataforma sem suporte), quando ninguém mais consegue mexer no código, ou quando a conta de conviver supera a conta de reescrever em menos de dois anos.

Existe ainda uma quinta opção que precisa entrar na mesa: trocar por um software pronto. Se o que o seu sistema faz hoje é resolvido por um SaaS de mercado a R$ 500 por mês, pagar dívida técnica em sistema próprio é dinheiro jogado fora. A gente diz isso ao cliente quando é o caso.

Os critérios que decidem se vale a pena pagar a dívida agora

Antes de aprovar qualquer orçamento de melhoria técnica, pergunta isso:

1. Esse módulo vai mudar nos próximos 12 meses? Se não, deixa como está. Dívida em código parado não cobra juros.
2. Quanto tempo leva hoje uma mudança pequena, e quanto deveria levar? Se a proporção passa de duas vezes, o juro já é alto. Peça essa comparação ao fornecedor por escrito.
3. Quantos incidentes esse módulo causou nos últimos seis meses? Mais de um por mês é sinal de que a reforma se paga só em correções evitadas.
4. Quantas pessoas conseguem mexer nesse código? Se a resposta é uma, você tem um risco de continuidade, não só um custo. Isso muda a prioridade.
5. A base tecnológica ainda tem suporte? Versões sem atualização de segurança são dívida com prazo, não dívida opcional. LGPD e segurança entram aqui.
6. Existe alguma decisão de negócio bloqueada pela dívida? Uma integração, um canal novo, um app. Se sim, o custo de oportunidade provavelmente supera o custo da reforma.

Três respostas ruins em seis: paga a dívida daquele módulo, agora, de forma isolada. Uma ou nenhuma: convive e revisa em seis meses. Cinco ou seis, com base sem suporte: comece a orçar a reescrita antes que ela vire emergência.

O que pedir ao fornecedor

Dívida técnica invisível é a mais cara. Peça ao time que mantém o sistema, seja interno ou externo, uma lista simples: os cinco pontos que mais atrasam mudanças, o que custaria resolver cada um e o que acontece se não resolver. Uma página basta. Se o fornecedor não consegue produzir essa lista, você já aprendeu algo sobre o fornecedor.

Como a gente lida com dívida técnica na OCA

Boa parte do que a OCA faz em software sob medida começa em sistemas que outra equipe construiu. Antes de tocar em qualquer código herdado, a gente faz uma avaliação de uma a duas semanas: mapeia os módulos, mede o custo de mudança em cada um, lista a dívida com preço ao lado e entrega esse relatório mesmo que o cliente decida seguir com outro time.

Também pagamos a nossa própria dívida. O Revo App, nossa plataforma de eventos, tem mais de 40 mil usuários e processa mais de 300 eventos por mês em cima de um checkout que converte a 90%. Uma base com esse volume de uso e de evolução acumula atalho como qualquer outra. A diferença é que a reforma entra no planejamento junto com as funcionalidades novas, com fatia de esforço reservada, porque a gente sabe pela própria conta que adiar sai mais caro. É essa prática que levamos para o sistema do cliente. Se quiser ver outros sistemas que operamos em produção, o portfólio da OCA tem os casos.

O próximo passo: a conta antes do contrato

Faça o exercício da tabela acima com o seu sistema. Pegue as últimas cinco mudanças pedidas, anote quanto tempo cada uma levou do pedido à entrega e compare com o que um dev sênior estimaria em código saudável. Some os incidentes dos últimos seis meses. Em uma hora você tem um número, e esse número decide a conversa: se a dívida custa R$ 2 mil por mês, convive. Se custa R$ 10 mil, reforma o módulo. Se está bloqueando o negócio, conversa com quem faz isso todo dia.

Se quiser uma segunda opinião sobre o seu sistema, com a lista de dívida precificada, é assim que a gente começa qualquer projeto de evolução ou resgate.

Converse com a OCA sobre o seu sistema