Dívida técnica: o que é, quanto custa para o seu negócio e como saber se a sua já venceu
Rafael Oliveira · · 6 min de leitura
O sistema funcionava bem. Hoje, qualquer mudança pequena leva semanas. O time de desenvolvimento pede prazo para coisas que pareciam simples, cada entrega quebra algo que já funcionava, e ninguém consegue explicar direito por quê. Se você é dono ou gestor de uma empresa que depende de um software próprio, provavelmente já viveu essa conversa: "não dá para mexer nisso agora, o código não ajuda".
Esse fenômeno tem nome: dívida técnica. E, como toda dívida, ela cobra juros. A diferença é que ninguém te manda boleto. O custo aparece disfarçado de prazo estourado, orçamento inchado e funcionalidade que nunca sai. Quem já passou por um projeto travado sabe do que estou falando.
O que é dívida técnica, sem jargão
Dívida técnica é o custo acumulado de decisões de desenvolvimento que priorizaram velocidade no curto prazo em troca de manutenção mais cara no longo prazo. Não é sinônimo de código ruim ou de time incompetente. Muitas vezes é uma decisão correta: lançar o MVP em oito semanas com atalhos conscientes pode ser melhor negócio do que lançar em vinte semanas com tudo perfeito.
O problema não é contrair a dívida. O problema é não saber que ela existe, não amortizar nunca e continuar construindo em cima. É como financiar um carro, esquecer as parcelas e se surpreender quando o guincho chega.
Na prática, dívida técnica aparece como:
- Código sem testes automatizados: cada mudança exige testar tudo manualmente, e mesmo assim algo escapa.
- Partes do sistema que só um desenvolvedor entende, e que ninguém mais ousa tocar.
- Versões antigas de linguagens e bibliotecas que não recebem mais atualização de segurança.
- Funcionalidades duplicadas ou remendadas, porque era mais rápido copiar do que reorganizar.
- Ausência de documentação: o conhecimento mora na cabeça de pessoas, não no projeto.
Quanto a dívida técnica custa em reais
Não existe resposta única, mas existe conta certa. A dívida técnica cobra em quatro frentes, e todas podem ser medidas:
1. Custo de mudança
Uma funcionalidade que em um sistema saudável levaria 20 horas de desenvolvimento pode levar 60 em um sistema endividado. Se a hora do time custa R$ 150, essa diferença é R$ 6.000 a mais por funcionalidade. Multiplique por dez ou quinze mudanças por ano e você tem R$ 60.000 a R$ 90.000 anuais pagos só em juros, sem amortizar nada do principal.
2. Custo de defeito
Sistema sem testes quebra em produção. Cada incidente tem custo direto (horas de correção emergencial) e indireto (venda perdida, cliente irritado, equipe parada). Se o seu checkout fica fora do ar num sábado à noite, o prejuízo não aparece na fatura do desenvolvedor, mas aparece no faturamento.
3. Custo de oportunidade
Esse é o mais caro e o menos visível. Enquanto o time gasta 40% do tempo apagando incêndio e contornando código frágil, o concorrente lança a integração que o seu cliente pediu. Dívida técnica alta transforma a empresa em refém do próprio sistema: a estratégia passa a ser decidida pelo que o software aguenta, não pelo que o mercado pede.
4. Custo de pessoas
Bons desenvolvedores não ficam em projetos onde só se apaga incêndio. Rotatividade em time técnico custa caro: cada troca leva meses de rampa e leva embora conhecimento que não estava documentado, o que aumenta ainda mais a dívida. É um ciclo que se retroalimenta.
Os sinais de que a sua dívida já venceu
Antes de assinar qualquer contrato de "reescrever do zero", pergunta isso ao seu time ou fornecedor:
- Mudanças pequenas levam semanas? Trocar um texto, adicionar um campo, ajustar um relatório. Se tarefas de horas viram tarefas de semanas, os juros estão altos.
- Toda entrega quebra algo que funcionava? Regressões frequentes indicam ausência de testes automatizados, um dos tipos mais caros de dívida.
- Existe alguma parte do sistema que "ninguém mexe"? Se sim, você tem uma área do seu negócio congelada por medo, não por decisão.
- O sistema depende de uma pessoa específica? Se o desenvolvedor original sair, quanto tempo até alguém novo conseguir dar manutenção? Se a resposta é "meses" ou "não sei", esse risco tem preço.
- As tecnologias usadas ainda recebem atualização? Rodar versões descontinuadas de framework ou banco de dados é dívida com juros de segurança: além de caro, é passivo jurídico com a LGPD na mesa.
Duas respostas ruins nessa lista pedem atenção. Quatro ou cinco pedem plano de ação agora.
Reescrever do zero quase nunca é a resposta
O barato que sai caro aqui é o seguinte: diante de um sistema endividado, a proposta sedutora é jogar tudo fora e refazer "do jeito certo". Na maioria dos casos, é a pior decisão financeira possível. Reescrever significa pagar de novo por tudo que já funciona, congelar evoluções por meses e apostar que o novo time não vai cometer erros novos, o que raramente se confirma.
Na OCA, boa parte dos projetos que recebemos são sistemas herdados de outros times, e o caminho que costuma fazer sentido é outro:
- Auditoria primeiro. Mapear onde a dívida está concentrada. Ela nunca é uniforme: em geral, 20% do código causa 80% da dor.
- Estancar o sangramento. Colocar testes automatizados nas áreas críticas (pagamento, cadastro, o que gera receita) antes de qualquer mudança grande.
- Amortizar por partes. Refatorar os módulos problemáticos um a um, mantendo o sistema no ar e entregando valor no meio do caminho, em vez de uma grande reescrita de tudo.
- Orçar a manutenção como linha fixa. Reservar de 15% a 20% da capacidade do time para pagar dívida continuamente. Empresas que fazem isso raramente chegam ao ponto de crise.
Existe exceção: quando a tecnologia base foi descontinuada, quando não há mais ninguém no mercado que trabalhe com ela, ou quando o custo de manter supera o de refazer com folga comprovada em números. Mas essa conclusão deve vir de uma auditoria, não de uma opinião na primeira reunião.
Como contratar sem herdar dívida escondida
Se você está contratando desenvolvimento agora, dá para prevenir boa parte do problema no contrato e na conversa:
- Pergunte como o fornecedor lida com testes automatizados. "Testamos manualmente" é resposta insuficiente para qualquer sistema que processa dinheiro ou dados de cliente.
- Exija que o código fique em repositório seu, com documentação mínima de como rodar e publicar o sistema. Isso é o que separa um fornecedor de um sequestrador de projeto.
- Peça que atalhos conscientes sejam registrados. Time sério fala abertamente: "fizemos X mais simples para caber no prazo, o custo de arrumar depois é Y". Dívida documentada é dívida administrável.
- Desconfie do orçamento muito abaixo dos demais. Em desenvolvimento, preço fora da curva quase sempre significa dívida embutida que você vai pagar com juros no ano seguinte.
É por isso que a gente defende manutenção como parte do orçamento desde o dia um, não como surpresa do ano dois. No nosso próprio produto, o Revo App, que atende mais de 40 mil usuários e 300 eventos por mês, tratamos dívida técnica como item de rotina: um checkout que converte a 90% só se mantém assim porque o código que o sustenta recebe cuidado contínuo, não porque foi escrito perfeito na primeira vez.
O próximo passo prático
Ação gratuita para esta semana: aplique o checklist dos cinco sinais acima com quem mantém o seu sistema hoje. Anote as respostas. Só esse exercício já revela se você está pagando juros sem saber e dá material concreto para a conversa com qualquer fornecedor.
Se as respostas acenderam alerta, ou se você herdou um sistema que ninguém mais quer tocar, esse é exatamente o tipo de projeto que a gente constrói e resgata na OCA: auditoria honesta, plano de amortização por etapas e a recomendação de não refazer quando refazer não compensa.
