Dívida técnica: o que é, quanto custa para o seu negócio e quando vale pagar (os sinais, a conta em reais e os 4 caminhos em 2026)

Seu sistema funciona. Não cai, o faturamento passa por ele e a equipe usa todo dia. Mas toda vez que você pede uma alteração, a resposta chega acompanhada de um suspiro. Um campo novo no cadastro, que deveria levar dois dias, levou três semanas. A última mudança no relatório de vendas quebrou a emissão de boletos, e ninguém soube explicar por quê. Antes de qualquer coisa nova, o fornecedor fala em “mexer na base”, e cada orçamento de melhoria sai maior que o anterior.

Isso não é preguiça nem má-fé de ninguém. Você está pagando juros de uma dívida que talvez nem saiba que contraiu. O nome técnico é dívida técnica, e ela tem preço em reais. Dá para medir, dá para decidir quanto pagar e, em alguns casos, a decisão certa é não pagar nada.

O que é dívida técnica, sem jargão

Todo atalho tomado para entregar mais rápido funciona como um empréstimo. Você ganha prazo hoje e paga juros em cada alteração futura. O juro aparece como horas extras, bugs que surgem do nada e medo de mexer em certas partes do sistema.

O ponto que muita gente esquece: boa parte da dívida técnica foi uma decisão correta na época. Um MVP que precisava ir ao ar em oito semanas não tinha que ter arquitetura de banco. O problema começa quando o MVP vira o produto principal e ninguém volta para revisar o que foi feito às pressas.

As causas mais comuns que encontro quando assumo um sistema em produção:

• Prazo apertado sem revisão depois. O atalho era temporário, mas virou permanente.
• Ausência de testes automatizados. Sem eles, toda mudança exige testar tudo na mão, ou não testar.
• Dependências envelhecidas. Versões de framework, banco ou bibliotecas que pararam de receber atualização de segurança.
• Conhecimento que saiu pela porta. O dev que entendia o módulo de cobrança foi embora e não deixou documentação.
• Regras de negócio empilhadas. Cinco anos de exceções para clientes específicos, cada uma num lugar diferente do código.

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

Dívida técnica parece abstrata até você colocar em horas. A conta mais simples compara quanto uma funcionalidade deveria custar num sistema saudável com quanto ela custou no seu.

Exemplo realista: uma funcionalidade estimada em 40 horas num sistema bem estruturado leva 120 horas no seu. São 80 horas de juros. A R$ 180 por hora de um dev sênior, isso dá R$ 14.400 de juros em uma única entrega. Se você entrega uma funcionalidade desse porte por mês, a dívida cobra perto de R$ 170 mil por ano sem aparecer em nenhuma linha do orçamento com esse nome.

Esse número muda com o valor da hora (entre R$ 120 e R$ 220 para sênior no Brasil em 2026), com o tamanho das entregas e com a frequência de mudanças. Um sistema que quase não recebe alteração cobra poucos juros, mesmo com código ruim.

Os juros não aparecem só no tempo de desenvolvimento:

Quem já passou por um projeto travado sabe do que estou falando: o custo mais alto raramente é o código. É a operação esperando.

Refatorar, reescrever ou conviver: os 4 caminhos

Não existe resposta única, mas existe conta certa. Na prática, toda decisão sobre dívida técnica cai em um destes quatro caminhos.

1. Pagar aos poucos, junto com as funcionalidades

Você reserva de 15% a 25% das horas de cada ciclo para melhorar a parte do sistema que está sendo alterada. Não há projeto separado nem pausa nas entregas. É o caminho padrão para a maioria dos sistemas que funcionam mas ficaram lentos para evoluir. O custo fica diluído no contrato de evolução que você já paga.

O barato que sai caro aqui é o seguinte: cortar essa reserva para “entregar mais coisas este trimestre”. Funciona por três ou quatro meses. Depois, cada entrega custa mais que a anterior.

2. Parar para refatorar um módulo específico

Quando um módulo concentra a maioria dos incidentes (cobrança, estoque, integração com o ERP), vale um projeto focado nele. Faixa típica em 2026: R$ 15 mil a R$ 60 mil, em 3 a 8 semanas, dependendo do tamanho do módulo e da existência de testes. O sistema continua no ar durante o trabalho.

3. Reescrever o sistema

É o caminho que todo dev novo no projeto sugere e o que menos recomendo. Reescrever custa o mesmo que construir um sistema novo, com frequência de R$ 60 mil a R$ 250 mil, e por três a nove meses você mantém dois sistemas: o antigo, que ainda roda a operação, e o novo, que ainda não está pronto. Faz sentido em poucos casos: a tecnologia base perdeu suporte e não tem caminho de atualização, ninguém consegue publicar uma versão com segurança, ou o negócio mudou tanto que o sistema antigo resolve o problema errado.

4. Conviver de propósito

Às vezes a melhor decisão é não pagar a dívida. Dívida em código que ninguém altera não cobra juros. Conviva com ela quando:

• o sistema será substituído nos próximos 12 meses;
• a parte problemática é um módulo estável que ninguém precisa mexer;
• um SaaS pronto resolve aquela função por menos do que custaria arrumar o código. Nesse caso, migre e desligue o módulo.

Esse último ponto é sério. Se o seu módulo de agendamento custa R$ 30 mil para refatorar e um SaaS de agendamento custa R$ 400 por mês, a conta está feita.

Checklist: 7 perguntas para medir a dívida técnica do seu sistema

Você não precisa ler código para saber o tamanho do problema. Antes de aprovar o próximo orçamento, pergunta isso ao seu fornecedor ou ao seu time:

1. Quanto tempo leva hoje uma alteração simples, e quanto levava há um ano? Se o tempo dobrou, os juros estão subindo.
2. Quantos bugs do último mês vieram de uma mudança que quebrou outra parte? Mais de dois por mês indica acoplamento alto.
3. Existem testes automatizados? Que partes eles cobrem? “Testamos na mão” significa que cada entrega carrega risco.
4. Quantas pessoas conseguem publicar uma versão nova sem ajuda? Se a resposta é uma, você tem dívida e risco de pessoa-chave ao mesmo tempo.
5. As versões de linguagem, framework e banco de dados ainda recebem atualização de segurança? Peça a lista por escrito.
6. Existe documentação para subir o sistema do zero num ambiente novo? Sem isso, trocar de fornecedor vira arqueologia.
7. Qual parte do sistema vocês têm medo de mexer, e por quê? Todo time sabe responder. A resposta mostra onde está a maior dívida.

Se três ou mais respostas forem ruins, a dívida já está cobrando juros relevantes. Se uma ou duas forem ruins, o caminho 1 (pagar aos poucos) provavelmente resolve. Se a pergunta 5 voltar com versões sem suporte, trate como prioridade de segurança, não como melhoria.

Diagnóstico de dívida técnica: onde a OCA entra

Esse é o tipo de trabalho que a gente faz no dia a dia, porque também é dono de sistema em produção. O Revo App, nossa plataforma de eventos e ingressos, tem mais de 40 mil usuários, mais de 300 eventos por mês e um checkout que converte 90%. Evoluir um produto assim sem parar a operação exige decidir toda semana o que pagar agora e o que deixar para depois. O sistema de Gestão para Imobiliárias, também em produção, passa pelo mesmo exercício. Você pode ver esses e outros casos no portfólio de projetos da OCA.

Quando um cliente chega com um sistema lento para evoluir, o primeiro passo é um diagnóstico técnico com prazo e preço fechados: de 1 a 3 semanas, na faixa de R$ 5 mil a R$ 15 mil conforme o tamanho do sistema. O resultado é um documento com a dívida mapeada por módulo, a estimativa de juros em horas e reais, e a recomendação entre os quatro caminhos. Às vezes a recomendação é conviver ou trocar um módulo por SaaS, e a gente diz isso. Time sênior, sem júnior aprendendo no seu orçamento, e a mesma equipe que faz o diagnóstico executa o plano, se você quiser.

O próximo passo para o seu sistema

Uma ação gratuita para esta semana: envie as 7 perguntas acima para quem mantém o seu sistema hoje e anote as respostas. Repita daqui a três meses. Se os números pioraram, você terá dados concretos para decidir, e não só a sensação de que tudo está ficando caro.

Se quiser uma segunda opinião sobre as respostas ou um diagnóstico completo, fale direto com quem escreve o código:

Converse com a OCA sobre o seu sistema