O que é dívida técnica e quanto ela custa para o seu negócio: a conta que ninguém mostra

Toda funcionalidade nova demora mais do que a anterior. O relatório que levava dois dias para ajustar agora leva duas semanas. O dev que cuida do sistema avisa que "mexer ali é arriscado" e ninguém consegue explicar exatamente por quê. Se você reconhece essa cena, o problema provavelmente não é equipe lenta nem falta de empenho. É uma dívida acumulada dentro do código, cobrando juros a cada mudança. Entender o que é dívida técnica é o primeiro passo para parar de pagar esses juros sem saber. Neste artigo eu explico o que ela é, de onde vem, quanto custa em horas e reais, e como decidir entre pagar, conviver ou recomeçar.

O que é dívida técnica, na prática

Dívida técnica é todo atalho tomado no desenvolvimento de um software que economiza tempo agora e cobra tempo depois. A analogia com dívida financeira é precisa: existe um principal, que é o retrabalho necessário para arrumar o atalho, e existem os juros, que é o tempo extra que toda mudança futura leva enquanto o atalho continua lá.

Um exemplo concreto: para lançar antes, o time gravou a regra de cálculo de frete direto em três telas diferentes, em vez de centralizar em um lugar só. Funcionou. Seis meses depois, a transportadora mudou a tabela. Agora a alteração precisa ser feita três vezes, testada três vezes, e uma das três foi esquecida. O cliente recebeu frete errado por duas semanas. Isso é a dívida cobrando juros.

Dívida técnica não aparece em relatório financeiro. Ela aparece disfarçada de "estimativa que dobrou", "bug que voltou" e "não dá pra integrar com esse sistema aí".

De onde a dívida vem (sem caça às bruxas)

Quase nunca a causa é incompetência. As fontes mais comuns que eu encontro em sistemas que herdo são estruturais:

• Prazo apertado com decisão consciente. O time sabia do atalho, o negócio precisava lançar. Escolha legítima na época.
• MVP que virou produto definitivo. O que foi construído para validar uma ideia em 3 meses está sustentando a operação há 3 anos, sem nunca ter sido reforçado.
• Rotatividade sem documentação. Quem tomou as decisões saiu, e o conhecimento saiu junto.
• Fornecedor que entregou e sumiu. Projeto fechado por escopo, sem plano de manutenção. O código foi escrito para passar na entrega, não para durar.
• Stack abandonada. Bibliotecas e versões que pararam de receber atualização, travando qualquer evolução e abrindo brechas de segurança.

Entender a origem importa porque o tratamento muda. Dívida de prazo se paga com refatoração planejada. Dívida de conhecimento se paga com documentação e transferência. Dívida de stack, às vezes, só se paga migrando.

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

O barato que sai caro aqui é o seguinte: a dívida não cobra uma vez, cobra todo mês. E a conta é maior do que parece porque ela aparece em quatro lugares ao mesmo tempo.

Colocando números realistas de mercado brasileiro em 2025: a hora de um desenvolvedor sênior custa entre R$ 120 e R$ 250, dependendo do modelo de contratação. Se a dívida faz uma funcionalidade de 40 horas virar uma de 90, cada entrega carrega de R$ 6.000 a R$ 12.500 de sobrepreço invisível.

No agregado é pior. Um time interno de três desenvolvedores custa, com encargos, algo entre R$ 45.000 e R$ 70.000 por mês. Em sistemas com dívida alta, é comum 30% a 40% desse tempo ir para apagar incêndio e contornar limitações, não para construir. São R$ 15.000 a R$ 28.000 mensais pagos em juros, todo mês, sem amortizar nada do principal.

Esse número varia com o tamanho do sistema e a criticidade da operação, mas a mecânica é sempre a mesma: quanto mais tempo a dívida fica parada, maior a fatia do orçamento que ela consome.

Os sinais de que o sistema já passou do ponto

Quem já passou por um projeto travado sabe do que estou falando. Antes de virar crise, a dívida dá sinais reconhecíveis:

• As estimativas do time só crescem, e ninguém consegue justificar tecnicamente o porquê.
• Existe um módulo que só uma pessoa "tem coragem" de mexer. Se essa pessoa sair, o módulo congela.
• Toda atualização em uma parte do sistema quebra outra parte aparentemente sem relação.
• Uma integração simples, como emitir nota fiscal ou conectar um gateway de pagamento, foi orçada em meses.
• O time gasta mais horas corrigindo e contornando do que entregando coisa nova.

Dois ou mais sinais dessa lista já justificam parar e fazer a conta antes de aprovar o próximo grande desenvolvimento em cima da mesma base.

O que é dívida técnica aceitável (e quando ela é até saudável)

Aqui vai a parte que pouca gente do meu lado do balcão admite: dívida técnica zero não existe e nem deveria ser a meta. Todo MVP bem feito carrega dívida proposital. Deixar a arquitetura de relatórios simples enquanto o produto ainda não validou o mercado é decisão correta, não negligência. Nós mesmos fazemos isso nos produtos que operamos.

A diferença entre dívida saudável e dívida tóxica está em duas perguntas: ela foi assumida conscientemente? E alguém sabe onde ela está? Dívida documentada, com plano de pagamento, é ferramenta de velocidade. Dívida invisível, que ninguém mapeou e que só aparece quando algo quebra, é bomba de efeito retardado. O problema nunca foi tomar o atalho. É esquecer que ele existe.

Pagar, conviver ou recomeçar: os critérios que decidem

Não existe resposta única, mas existe conta certa. Antes de decidir, responda estas cinco perguntas:

1. O sistema ainda sustenta a operação? Se sim, reescrever do zero raramente é a primeira opção. Reescrita total é o último recurso, não o primeiro.
2. Quanto custa cada mudança hoje? Compare as horas reais das últimas entregas com o que entregas parecidas custavam há um ano. Essa diferença são os juros.
3. Alguém entende o código? Se o conhecimento ainda existe, refatoração incremental é viável. Se ninguém entende, o custo de qualquer caminho sobe e o risco de manter tudo como está sobe junto.
4. A stack ainda recebe atualizações? Tecnologia sem suporte é dívida com vencimento marcado, porque uma hora uma exigência externa força a migração no pior momento possível.
5. Os juros de seis meses superam o custo do reparo? Se o time perde R$ 20.000 por mês em retrabalho, um projeto de refatoração de R$ 80.000 se paga em quatro meses. Se a perda é marginal, conviver com a dívida pode ser a decisão racional.

Na maioria dos casos que eu acompanho, a resposta certa é o meio termo: uma refatoração incremental, feita em paralelo com a operação, atacando primeiro os módulos que mais cobram juros. Algo entre 4 e 12 semanas de trabalho focado, sem parar o sistema, costuma recuperar a maior parte da velocidade perdida. Reescrita completa, quando é inevitável, é projeto de 4 a 8 meses e merece o mesmo rigor de contratação de um produto novo.

Onde uma equipe externa entra nessa conta

Uma parte relevante dos projetos que chegam na OCA não é "construa do zero". É "herde esse sistema e faça ele voltar a andar". Diagnóstico de dívida, refatoração incremental e retomada de sistemas que o fornecedor anterior abandonou são o tipo de trabalho que a gente faz com frequência, e é possível ver os projetos que a OCA mantém em produção para calibrar a expectativa.

A razão de eu confiar nessa abordagem é que a gente aplica no próprio produto: o Revo App, nossa plataforma de eventos, tem mais de 40 mil usuários e continua rápido depois de anos de evolução justamente porque a dívida é paga um pouco por mês, nunca acumulada até virar crise.

O próximo passo não exige contrato nenhum. Pegue as cinco perguntas da seção anterior e responda com dados dos últimos três meses: horas gastas em correção versus construção, entregas que estouraram estimativa, módulos que ninguém quer tocar. Esse levantamento é o briefing perfeito para qualquer conversa técnica séria.

Se a conta indicar que chegou a hora de agir, Converse com a OCA sobre o seu sistema. A primeira conversa é um diagnóstico honesto, inclusive quando a resposta certa for não mexer em nada por enquanto.