O comprador descobre dívida técnica depois de assinar. No due diligence, a equipe lê receita, margem, churn e coorte e deixa o código para depois. Depois disso, o preço já está fixado. O vendedor entra na mesma mesa sem número nenhum: o sistema está no ar, os testes passam e ninguém somou o custo de manter aquilo de pé.
As perguntas que ficam fora da lista
O comprador pergunta sobre LTV, CAC, receita recorrente e taxa de renovação. As perguntas de engenharia não entram: tempo do commit até produção, bugs por mês, quantas pessoas alteram o núcleo do sistema, quando as dependências centrais receberam a última atualização.
Essas respostas existem e custam uma tarde. Git, pipeline e repositório de issues guardam o dado. Alguém precisa abrir.
Cinco perguntas de engenharia para a due diligence
- Tempo de build e deploy. Do commit ao ambiente de produção, quanto tempo passa? Horas apontam pipeline saudável. Dias apontam fila de aprovação, teste manual e uma pessoa no caminho crítico de cada release.
- Bugs em produção. Quantos incidentes por mês nos últimos 12 meses e para onde curva a linha? Sistemas maduros mantêm taxa baixa e estável. Taxa subindo denuncia deterioração.
- Concentração de conhecimento. Quantas pessoas alteram o núcleo sem pedir ajuda? Menos de três, e o comprador herda um risco de saída que aparece na primeira ausência.
- Idade das dependências. Quando os pacotes centrais mudaram pela última vez? Pacote parado há dois anos carrega CVE conhecido e trava upgrade de linguagem por três sprints.
- Documentação de arquitetura. Existe um diagrama datado do ano passado? Página do Confluence de 2022 descreve o sistema de 2022.
Nicole Forsgren, Jez Humble e Gene Kim mediram em Accelerate (IT Revolution, 2018) a ligação entre desempenho de entrega e desempenho de negócio. Os mesmos números dizem ao comprador quanto a manutenção consome por trimestre.
Transformar achado em número
Some três estimativas. Estabilizar: corrigir vulnerabilidades, atualizar dependências, cobrir testes ausentes. Escalar: o que muda para o sistema aguentar o crescimento projetado. Ignorar: o que acontece se nada mudar, com indisponibilidade, perda de dados e exposição de dados.
O total entra na mesa de negociação. Em sistemas legados com mais de dez anos, o resultado costuma cair entre 15% e 40% do valor de aquisição.
Steve McConnell trata da estimativa de esforço em Software Estimation (Microsoft Press, 2006) e defende faixa com cenário otimista e pessimista em lugar de número fechado. Faixa comporta a discussão que começa quando o trabalho começa; número fechado vira atrito.
Três formas de fechar a lacuna
Ajuste de preço. O comprador desconta do valor da aquisição o custo estimado da dívida. É a via mais simples e se sustenta quando o número vem de evidência verificável.
Obrigações pós-fechamento. O vendedor assume itens específicos com prazo e multa. Funciona quando o time que gerou a dívida continua no lugar depois do fechamento.
Escrow. Parte do valor fica retida até os itens acordados chegarem a um patamar aceitável. Exige estruturação maior e cobre melhor a dívida que depende de trabalho interno.
O vendedor que mede antes de anunciar
Auditoria técnica antes de colocar a empresa à venda coloca o problema na mesa enquanto dá tempo de consertar. O vendedor corrige o que é barato, precifica o que é caro e chega ao due diligence com o número na mão. O comprador encontra um time que já olhou para dentro e pede desconto menor por incerteza.
