the deal lab #12 - como fazer uma business due diligence

Na semana passada, o Robinho contou a história de quando o banco de dados da Joga foi deletado por engano. Se você não leu, vale cinco minutos: the deal lab #11. Ele terminou com uma bola jogada pra mim: na prática, o quanto a qualidade técnica realmente pesa na decisão de compra?

Minha resposta curta: depende, o que estamos chamando de qualidade técnica?

Minha resposta longa é essa edição.

As análises começam +- no mesmo lugar: deck institucional com grandes números, visão de roadmap, P&L, balanço, contratos até chegar na DD financeira e nas contingências trabalhistas, passivos fiscais, etc. Isso é o básico (que nem sempre é bem organizado pelos vendedores). Mesmo antes da due diligence, os números ajudam a aterrissar ordem de magnitude e quais pedaços do business eu preciso ver com mais carinho.

Distribuído no tempo, as informações, especialmente as financeiras, costumam ter 2 facetas: histórico e projeções. Histórico descreve o que a empresa foi. Por definição, as projeções financeiras estão majoritariamente erradas (apesar de algumas serem úteis).

O comprador compra um futuro. Eu não tenho essa empresa e vou passar a ser responsável por tudo, responderei pelos erros, riscos, passivos, etc. A pergunta que constantemente um comprador faz é: nas minhas mãos, tenho capacidade de extrair valor dessa empresa a ponto do retorno sobre o capital investido ser maior do que se aplicado em outras iniciativas?

Essa resposta nem sempre aparece no EBITDA.

Depende de como o time opera quando o founder não está na sala. Depende de se o crescimento dos últimos três anos foi construído em cima de um canal saudável ou de uma brecha que pode fechar amanhã. Depende de se a base de clientes é fiel ou está ali por inércia. Depende de se a operação consegue escalar sem reescrever tudo do zero. Depende se as sinergias têm fundamento prático testado ou se estão só na planilha.

Essas coisas não aparecem no data room. Você tem que ir buscar.

Certa vez, analisei uma empresa que tinha tudo para ser uma boa aquisição. Fundadores excepcionais, empresa referência em categoria muito sinérgica, boa visão de produto e empresa crescendo de forma saudável e pegada/cultura muito parecida. O tipo de negócio e time que você quer ter.

Durante a análise, antes de colocar proposta na mesa, descobrimos que um pedaço relevante da receita dependia de uma integração com plataformas de terceiros que infringia políticas de uso. A integração técnica funcionava, mas era frágil e tinha um risco enorme de estourar uma bomba.

Não era má fé. Era um ponto cego. O negócio tinha crescido rápido, e ninguém tinha parado para checar se aquele caminho era sustentável pelas regras da plataforma. Em paralelo, a empresa era super organizada, orientada a dados, com documentação clara, tudo aparentemente bonitinho.

Pouco tempo depois, a plataforma penalizou a empresa. O canal que sustentava boa parte da tração simplesmente fechou e a receita despencou. Os fundadores depois consertaram. Mas na época, foi deal breaker.

Não era um risco mapeado pelo vendedor, nenhum contador teria encontrado esse risco no balanço ou nenhum advogado teria levantado isso numa due diligence jurídica padrão. Era um risco de negócio. Só apareceu porque alguém foi entender no detalhe como aquele negócio funcionava.

Tem n fornecedores no mercado para ajudar nas due diligence mais técnicas. Apesar das boutiques e assessorias estarem mais focadas em ajudar o sell-side do que o buy-side, acredito que cada empresa deveria criar e refinar seu modelo proprietário de business due diligence. Não é um checklist técnico. Está mais para um guia mestre das frentes que te interessam, a partir de uma pergunta central: qual problema do meu negócio essa aquisição resolve e como vou fazer que ele viva dentro do meu?

Isso significa entender algumas coisas que raramente aparecem nos relatórios:

Por que o cliente contrata essa empresa? Parece bobo, mas é destrinchando essa pergunta que eu mais aprendo sobre as empresas que analiso. Como ficou sabendo dessa empresa? Que problema você tava tentando resolver quando decidiu que precisava dessa solução? Avaliou concorrentes / alternativas? Por que não comprou dos concorrentes? Quanto tempo demorou até você achar que a vida ficou melhor com essa empresa? Se não ficou, por que continua pagando? O que mais gosta do produto? O que sente falta? Quando foi a última vez que precisou de suporte? Quanto tempo demorou para resolver?

PMs / designers fazem isso direto com clientes como parte do desenvolvimento de produto. É uma lógica bem similar (e poderosa)

De onde vem o crescimento? E até quando ele continua? Canal proprietário ou alugado? Crescimento orgânico ou dependente de mídia paga? A empresa está construindo um ativo ou comprando tração? Até onde dá pra chegar, qual o tamanho desse mercado?

Onde mora o conhecimento. O Robinho falou sobre isso pelo lado do vendedor: conhecimento que mora na cabeça das pessoas vai embora com elas. Pelo lado do comprador, a pergunta é: se os três principais executivos saírem no primeiro ano pós-fechamento, o que sobra? Como eu me preparo para reter o conhecimento mesmo quando nem todo está documentado?

Quais são as dependências ocultas. Plataformas, fornecedores, regulação, um cliente que representa 40% da receita. Toda empresa tem pontos de dependência. A questão é saber quais são e as alternativas para lidar com cenários de estresse.

Se a cultura vai colidir ou convergir. Esse é o mais difícil de medir e o mais caro de ignorar. Duas empresas com ritmos, valores e formas de tomar decisão muito diferentes podem criar uma integração que consome mais energia do que o deal vale. Cultura se conhece muito mais na convivência do que no assessment de RH. Parcerias de longo prazo e relações de cliente / fornecedor maximizam a probabilidade da integração ser mais suave.

Meu parceiro da thedeallab, o Robinho, me perguntou se a qualidade técnica realmente pesa, ou se é coisa de cabeça de engenheiro.

Não é coisa de cabeça de engenheiro. Código bem escrito, cobertura de testes, backups, documentação em dia: esses não são fins em si mesmos. São evidências de uma cultura de responsabilidade e organização. De um time que pensa no amanhã enquanto resolve o hoje, o que é difícil p/ caramba de balancear quando a empresa está no começo.

São sinais que reforçam que a integração das empresas pode ser bem conduzida (uma vez que o problema / encaixe está claro).

Eu citei um caso onde um red flag técnico foi deal breaker, mas raramente é algo que isoladamente afeta o deal. Mesmo no caso citado, era muito mais uma lição de casa para voltarmos a conversar do que um deal breaker. Mas se combinado com outros sinais, vira um quadro preocupante que o comprador não deveria querer assumir (documentação inexistente, informação conflitante / bagunçada, um negócio que só funciona porque um founder específico está acordado).

A DD técnica se faz mais necessária quando o valor que eu enxergo está nas linhas de código especificamente, na engenharia, nos componentes técnicos (e menos no produto ou no negócio).

Se a tecnologia está uma bagunça mas eu estou comprando o negócio e ele é bom? Vira desconto, não desistência. Se a bagunça técnica é sintoma de uma bagunça maior, aí o desconto começa a ter cara de deal breaker.

Sobre processos, vale a resposta sobre a cabeça de engenheiro. É muito mais um indício positivo do que um mínimo esperado. O comprador precisa encontrar um balanço entre ser profundo nas coisas que importam, e saber que algumas coisas estão ali, mas que para o momento de avaliação não precisam ser aprofundadas.

Daqui duas semanas, o Robinho me diz o que achou. Ou traz outro assunto e a gente discute. Aliás, começamos 2026 espaçando a newsletter para um formato quinzenal. Ainda estamos descobrindo o formato. Mas adoramos receber feedback dos leitores.

Obrigado ao Pedro da Drops pelos toques recentes e por ter lido nossas edições ❤