Due diligence técnica: o que o comprador deve verificar

Due diligence técnica é uma revisão estruturada do código, da infraestrutura, do time e da segurança de um produto de software, feita antes de você comprar, investir ou se fundir com uma empresa. O objetivo é descobrir se o que disseram sobre a tecnologia corresponde ao que realmente roda em produção, e quanto vai custar mantê-la funcionando e crescendo.

Como regra prática (estimativa minha, não um número de mercado), uma due diligence técnica focada leva de alguns dias a algumas semanas e termina com um relatório curto que classifica os riscos pelo efeito no preço, nas condições e no roadmap. É assim que eu conduziria, com base em sete anos construindo produtos de ponta a ponta e liderando a migração ao vivo de uma plataforma em produção para uma nova stack.

O que é due diligence técnica e quem precisa dela?

É a parte técnica da verificação de uma empresa antes de uma transação. Vale para aquisições, rodadas de investimento, fusões e compras de um produto de uma agência ou de um desenvolvedor solo. Também serve para fundadores que herdam uma base de código depois que um desenvolvedor sai, porque a pergunta é a mesma: o que exatamente é nosso, e o que vai ser preciso para manter isso vivo?

Quem normalmente precisa dela:

• Compradores adquirindo uma empresa de software ou um produto.
• Investidores cujo cheque depende principalmente do valor do software.
• Fundadores e CTOs assumindo um sistema de uma agência ou de um engenheiro que saiu.
• Empresas prestes a unir dois times de engenharia ou duas plataformas.

Ela é mais ampla e mais rasa do que uma auditoria de código. Uma auditoria lê o código a fundo. A due diligence cobre código, entrega, infraestrutura, segurança, pessoas e contratos, e distribui o tempo de acordo com o risco. Se ela encontra uma área preocupante, uma auditoria mais profunda dessa área pode vir em seguida.

Como é um processo de due diligence técnica?

Defina um prazo fechado. A sequência importa mais do que a duração, e ela espelha os primeiros 30 dias ao assumir um sistema.

1. Acessos. Peça acesso de leitura aos repositórios, ao console de nuvem, ao CI/CD, ao monitoramento de erros, ao analytics, ao registrador do domínio, às contas das lojas de apps e aos serviços de terceiros. Verifique quem é dono de cada conta: a empresa, uma agência ou uma pessoa física. Se o vendedor não consegue liberar acesso em um prazo razoável, isso já é um achado.
2. Build. Em uma máquina limpa, siga apenas a documentação escrita para fazer o build e rodar o produto. Rode os testes. Faça deploy em um ambiente de staging, se existir. Anote quanto tempo levou e o que faltava nas instruções.
3. Fluxos de dinheiro. Rastreie todo fluxo que gera ou movimenta dinheiro: cadastro, checkout, assinaturas, faturamento, repasses. Leia o código, os testes e o tratamento de erros de cada um. Trabalhar no time de carrinho e checkout da Total Wine & More me ensinou o quanto se esconde nos casos de borda desses fluxos, então é aqui que eu gasto as horas mais cuidadosas.
4. Riscos. Só então abra o escopo: segurança, dependências, dados, infraestrutura, pessoas e licenças.

Termine anotando o que você não conseguiu verificar. Afirmações não verificadas também são riscos, e o relatório deve dizer isso.

Quais perguntas revelam o estado real da base de código?

Vendedores costumam descrever o sistema como ele foi projetado, não como ele se comporta. Estas perguntas forçam respostas concretas, e a tabela mostra o que eu procuro ouvir.

Três hábitos em que eu confio:

• Leia o histórico do git. Quem fez commits no último ano, com que frequência, e os autores das partes críticas ainda estão por perto?
• Peça o último incidente em produção. Um time que consegue explicar o que quebrou, como descobriu e o que mudou depois costuma estar em melhor situação do que um que diz que nada nunca quebrou.
• Leia um fluxo de dinheiro de ponta a ponta. Uma hora no código de checkout ou de cobrança diz mais do que um deck de slides.

Como avaliar os riscos de time, infraestrutura e segurança?

Time

Liderar mais de 15 pessoas em web, mobile e e-commerce me ensinou que conhecimento na cabeça de uma só pessoa é o ativo que se deteriora mais rápido. Pergunte quem entende cada área crítica, quem está saindo e o que está documentado. Veja como o código é revisado e como as releases são decididas. Se o produto foi construído por uma agência ou por contractors, confirme quem continua sob contrato depois do fechamento. Se a empresa é de fato dona do código escrito por eles é uma questão jurídica, então peça a um advogado para revisar os contratos. Sobre práticas de release, pergunte se usam deploy canário para expor mudanças primeiro a poucos usuários.

Infraestrutura

Estes são os itens que eu verifico primeiro:

• Se a conta de nuvem pertence à empresa, e não a um ex-desenvolvedor ou a uma agência.
• Se a infraestrutura está descrita em código ou vive na memória de alguém e em um console. Se dados passam entre bancos durante uma migração, pergunte se change data capture mantém os dois sincronizados.
• Se existem backups e, mais importante, se alguém já restaurou um. Peça um teste de restauração.
• Se existem monitoramento e alertas, e quem é acionado.
• Pontos únicos de falha, e a tendência da conta de nuvem comparada ao uso.

Segurança

Você não precisa de um pentest completo para encontrar o básico. Procure segredos commitados no histórico do repositório. Veja como funcionam a autenticação e a autorização, quem tem acesso de admin e se ex-funcionários e contractors foram removidos. Rode uma varredura de vulnerabilidades nas dependências e leia os resultados com contexto. Revise como dados pessoais são armazenados e registrados em log. Se o backend depende de um banco de dados hospedado com regras de acesso, como row level security, confirme que essas regras estão de fato ativadas e testadas. Obrigações de compliance, como leis de privacidade ou questionários de segurança de clientes, ficam com um advogado ou especialista em compliance.

O que um relatório de due diligence técnica deve incluir?

Mantenha-o curto o bastante para que alguém que não é engenheiro consiga agir a partir dele. Uma estrutura útil:

• Resumo e veredito. Dois parágrafos: o produto é o que o vendedor afirma, e quais são os maiores riscos?
• Escopo. O que foi revisado, como, e o que não pôde ser verificado.
• Visão geral do sistema. Stack, hospedagem, serviços de terceiros e um esboço simples da arquitetura.
• Achados classificados por gravidade. Cada um com evidência (um arquivo, um print, um passo que falhou), não opinião.
• Estimativas de esforço. Faixas, claramente identificadas como estimativas, para corrigir os principais achados.
• Dependência de pessoas. Quem detém conhecimento crítico e o que acontece se essas pessoas saírem.
• Primeiros 30 e 90 dias. O que fazer logo depois do fechamento.
• Perguntas em aberto para o vendedor. Itens a resolver antes de assinar.

Evite notas de zero a dez sem explicação. Quem decide precisa saber o que cada achado significa, quanto custa e qual é o próximo passo.

Quais achados devem mudar o negócio ou o roadmap?

Achados que mudam o negócio

• O vendedor não controla os ativos: código, domínio, conta de nuvem ou página na loja de apps estão com um terceiro.
• Os fluxos de receita não podem ser verificados, ou os fluxos de dinheiro estão quebrados de formas que os usuários ainda não perceberam.
• Um incidente de segurança não declarado ou dados de clientes expostos.
• Possíveis problemas de licenciamento no código ou nas dependências, a serem confirmados por um advogado.
• O sistema inteiro depende de uma pessoa que não vai ficar.

Dependendo da gravidade, as respostas podem ir de um preço menor a condições que precisam ser cumpridas antes do fechamento, retenções de pagamento, ou desistir do negócio. Como estruturar essas condições é uma pergunta para o seu advogado, não para um engenheiro.

Achados que mudam o roadmap

A maioria dos achados não derruba um negócio. Eles redesenham o primeiro trimestre: frameworks sem suporte, falta de testes nos fluxos críticos, deploys manuais, backups sem teste de restauração. Arrume a rede de segurança primeiro, depois mude o produto.

Se os achados apontam para a troca da stack, resista ao instinto de planejar uma reescrita. Uma reescrita normalmente custa mais e demora mais do que uma migração incremental, porque o sistema antigo precisa continuar rodando em paralelo. Eu prefiro colocar um ponto de desvio na frente de tudo antes de escrever código novo, e então mover o sistema peça por peça enquanto ele continua no ar. Foi assim que conduzi a migração completa de uma plataforma que se candidata a vagas de emprego automaticamente, enquanto os usuários continuavam usando todos os dias.

Quer uma segunda opinião sobre o seu caso?

Se você está prestes a comprar, investir ou herdar um produto, mande um email para me@filipeeduardo.dev com a stack e o que está em jogo, e eu digo o que verificaria primeiro.