O que os dados de entrega revelam antes de adquirir uma empresa de software

É possível aprender muito sobre uma empresa de software em poucas semanas de due diligence e, ainda assim, deixar escapar o que mais importa depois da aquisição: qual é a dificuldade dessa equipe para continuar evoluindo o software?

Essa pergunta aparece com frequência nos relatos de fundadores e engenheiros que passaram por uma aquisição. Um fundador contou que esperava que a dívida técnica reduzisse a avaliação da empresa, mas acabou vendo o assunto receber pouca atenção nas negociações. Um engenheiro, em outra discussão, colocou a questão de forma mais útil: a dívida só se torna um problema de negócio quando cada nova funcionalidade começa a custar mais do que a anterior. Os dois apontam para a mesma ideia. O estado do código em um determinado momento revela menos do que seu comportamento quando alguém precisa alterá-lo.

É isso que os dados de entrega mostram, e é a parte que uma revisão de código não consegue alcançar.

Observe como o trabalho avança, não apenas sua aparência

Uma revisão de código é uma fotografia. Ela mostra como o software está no dia em que alguém o examina. O histórico de entrega se aproxima mais de um filme: mostra o que acontece toda vez que a equipe precisa fazer uma mudança.

Quanto tempo uma alteração leva para chegar à produção? Quanto tempo o código pronto fica esperando uma revisão? Com que frequência uma implantação exige outra para corrigir os problemas que deixou? Essas perguntas parecem fazer parte da rotina da engenharia, mas cada uma mede a distância entre “decidimos fazer isso” e “isso está disponível para os clientes”. Essa distância faz parte do que você está adquirindo.

A DORA estuda esse tema há mais de uma década. Seu modelo atual acompanha o tempo entre uma alteração no código e sua chegada à produção, a frequência de implantação, o tempo de recuperação após uma implantação com falha, a taxa de falha das mudanças e o retrabalho nas implantações. A DORA apresenta essas métricas como indicadores da capacidade de uma equipe de entregar com segurança e eficiência.

A armadilha está em se prender a um único número. O que merece atenção é o comportamento dos dados ao longo do tempo. Um prazo de entrega que vem aumentando discretamente há um ano diz mais do que um prazo que parece alto neste trimestre. A empresa pode continuar cumprindo seu roadmap. Mas, se cada mudança exige mais coordenação e mais retrabalho do que há doze meses, você está diante de um sistema que exige cada vez mais esforço para evoluir.

Há duas ressalvas a considerar. Equipes pequenas geram dados sujeitos a grandes oscilações, e uma migração de grande porte ou um período sabático do fundador pode distorcer um gráfico sem indicar um problema estrutural. Além disso, muitas boas empresas simplesmente não coletam esses dados com qualidade suficiente para apresentar números confiáveis durante a due diligence. A ausência de dados também é um sinal, mas não é automaticamente um sinal ruim.

A espera costuma explicar boa parte do problema

Se houver apenas um ponto para examinar, olhe para os pull requests.

Um desenvolvedor pode concluir uma alteração em uma tarde e depois esperar dias até que alguém a revise. A própria revisão pode exigir várias rodadas de ajustes. Depois da aprovação, a alteração pode voltar a ficar parada antes de chegar à produção. Nada dessa espera aparece em uma demonstração do produto ou no código, mas é justamente aí que muitas vezes está boa parte do custo de fazer mudanças.

É fácil subestimar a dimensão dessa espera. O benchmark de 2026 da LinearB, que abrange mais de 8,1 milhões de pull requests de mais de 4.800 equipes, apresenta medidas separadas para etapas como desenvolvimento e espera pelo início da revisão.

Para os líderes, a pergunta útil é onde o tempo de espera está aumentando. O tempo total de ciclo de uma equipe pode parecer estável mesmo quando as alterações passam cada vez mais tempo aguardando alguém para revisá-las.

Para um comprador, o ponto não é saber se a empresa supera um benchmark externo.

A pergunta útil é se os dados da própria empresa mostram um processo estável ou um gargalo que vem crescendo enquanto todos estavam ocupados fazendo entregas.

Velocidade e retrabalho não são a mesma coisa

Uma equipe pode parecer rápida simplesmente porque faz implantações frequentes. Essa leitura muda quando você percebe quantas dessas implantações servem para corrigir problemas.

É por isso que a DORA passou a acompanhar o retrabalho nas implantações como uma métrica própria: a proporção de implantações realizadas para resolver problemas causados por uma implantação anterior em produção. Dez implantações em uma semana contam uma história muito diferente quando três delas foram correções não planejadas para as outras sete.

Engenheiros costumam desconfiar de números de produtividade apresentados sem esse contexto, e têm razão. A preocupação recorrente é a lei de Goodhart na prática: quando uma métrica se torna uma meta, a equipe pode melhorar o número sem melhorar o que está por trás dele. É fácil manipular a frequência de implantação; manter uma frequência saudável com pouco retrabalho é muito mais difícil de simular. Por isso, o que se deve buscar na due diligence não é um número que cause uma boa impressão. É verificar se os números são coerentes entre si.

O histórico de entrega revela de quem a empresa realmente depende

Antes de uma aquisição, os investidores precisam entender de quem vem o conhecimento necessário para manter o software funcionando e evoluindo. Uma empresa pode ter dez engenheiros no papel, mas apenas um ou dois com o conhecimento necessário para alterar seus sistemas mais críticos com segurança.

O histórico de entregas e dos repositórios ajuda a identificar essa dependência. Quem contribui para os componentes críticos? Outros engenheiros conseguem manter essas partes sem ajuda? A concentração de atividade é um motivo para investigar mais a fundo, especialmente quando as entrevistas revelam que conhecimentos essenciais nunca foram compartilhados.

A Avalia já encontrou essas consequências na prática. Em um caso descrito num artigo de 2022 sobre sinais de alerta em negócios de tecnologia, a due diligence de software identificou o risco de perder uma engenheira essencial. Quando ela foi procurada após a conclusão da aquisição, já era tarde demais. Em 2026, esse risco continua relevante: as ferramentas e as práticas de desenvolvimento evoluíram, mas conhecimentos críticos ainda podem estar concentrados em pessoas cuja saída coloca em risco o plano pós-aquisição.

Para um investidor, essa dependência pode afetar a capacidade da empresa de executar o plano pós-aquisição. Identificá-la antes da assinatura dá ao comprador tempo para discutir a retenção dessas pessoas e definir como o conhecimento crítico será transferido. Também oferece uma base mais sólida para avaliar o esforço e os riscos envolvidos em assumir o software.

A pergunta nunca foi se a equipe é rápida

A due diligence técnica tradicional se concentra em arquitetura, segurança, infraestrutura e qualidade do código, e deve continuar fazendo isso. Os dados de entrega respondem a uma pergunta diferente e complementar: quanto custa, na prática, para essa empresa usar sua tecnologia em uma terça-feira qualquer?

As duas análises nem sempre apontam na mesma direção. Um código bem organizado pode fazer parte de um processo de entrega lento, no qual cada mudança exige uma negociação. Um código mais desorganizado pode ser conduzido com facilidade por uma equipe que conhece profundamente seus problemas e particularidades. Nenhuma dessas situações, por si só, inviabiliza uma aquisição. Mas elas representam empresas muito diferentes para quem assume o negócio, e a demonstração do produto não revela qual delas está à sua frente.

Você não está tentando encontrar uma organização de engenharia perfeita; elas não aparecem à venda. Está tentando entender com que facilidade essa empresa conseguirá continuar evoluindo seu produto depois da aquisição, e quanto dessa capacidade irá embora se a pessoa errada sair.