Technical due diligence: o guia de preparação do fundador não-técnico

O e-mail chega numa terça à tarde. O lead investor da sua Série A está “quase lá” e contratou uma firma de technical due diligence. O time de TDD vai precisar de acesso de leitura ao repositório, uma call de 60 minutos com quem cuida do build e a lista de todos os serviços de terceiros dos quais o produto depende. O kickoff é segunda. Você encaminha o e-mail para o seu único desenvolvedor e fica sentado com a pergunta que todo fundador não-técnico aprende a temer no primeiro dia de uma rodada de verdade: o que exatamente está prestes a acontecer com a minha empresa.

Technical due diligence é uma auditoria independente do software, da infraestrutura e das práticas de engenharia de uma empresa, encomendada por um investidor ou comprador antes de fechar o aporte. Ela existe para responder a uma única pergunta: o produto que a empresa vende corresponde à realidade de engenharia por trás dele? A auditoria cobre qualidade de código, arquitetura, segurança, capacidade do time e a disciplina operacional que sustenta o stack inteiro. Para um fundador não-técnico, é a primeira vez que um terceiro com lanterna na mão olha por dentro da caixa.

Este é o guia do fundador para essa auditoria. O que os investidores realmente olham, os sete red flags que reprovam deals e um playbook de quatro semanas de preparação que resolve a maioria deles.

O que technical due diligence é, na prática

A definição de manual cabe em uma frase: technical due diligence é a revisão estruturada que um comprador encomenda para confirmar que aquilo que ele está comprando ou financiando se sustenta tecnicamente. O comprador costuma ser um fundo de venture capital numa Série A ou B, um comprador estratégico em M&A, um fundo de private equity num deal de growth, ou ocasionalmente um cliente enterprise prestes a assinar um contrato grande o bastante para justificar o trabalho.

A auditoria leva de uma a quatro semanas. Envolve um time pequeno (em geral dois a quatro engenheiros de uma firma especializada como Snyk, MEV, TechCXO ou uma boutique como Quandary Peak) rodando um playbook fixo: code review, entrevista de arquitetura, scan de segurança, entrevistas com o time e um relatório escrito entregue ao comprador. O relatório não vai para a empresa auditada a menos que ela peça. O comprador lê sozinho e decide o que fazer com os achados.

Dois termos costumam ser usados de forma intercambiável e vale desambiguar de uma vez. Technical due diligence e technology due diligence são, na prática, a mesma coisa. Algumas firmas preferem um nome; o produto final é idêntico. Em construção civil e em real estate, TDD se refere a um processo completamente diferente (auditoria estrutural de um imóvel). Se um resultado de busca sobre o tema não menciona software, não é o documento que você está procurando.

Por que isso está acontecendo com você agora

TDD aparece em quatro momentos específicos na vida da empresa, e o gatilho costuma dizer no que a auditoria vai focar.

O primeiro é uma rodada Série A. O lead leu o deck, viu a demo e agora está estressando se o produto aguenta dez vezes a carga que tem hoje. A TDD aqui é forward-looking: este time de engenharia consegue, de fato, entregar o roadmap que está no slide?

O segundo é M&A. Ou um comprador estratégico quer absorver a empresa, ou um private equity quer uma posição de controle. Essa TDD é focada em risco. O comprador está pagando um múltiplo de receita, e precisa garantir que não está comprando também um passivo técnico do tamanho do preço.

O terceiro é uma rodada late seed ou estratégica onde um investidor sofisticado (Tiger, Sequoia, um braço de corporate venture de primeira linha) faz uma TDD leve como parte do processo de convicção. Essa é mais curta, em geral só um code review e uma call de arquitetura, e costuma ser informal.

O quarto, e o que a maioria dos fundadores não vê chegando, é o cliente flagship. Um banco, uma rede de hospitais, uma telco grande: qualquer contrato grande o bastante para justificar o jurídico do comprador acaba incluindo uma cláusula que exige uma TDD antes do contrato entrar em vigor. Já vimos isso bater em empresas pré-Série A que achavam que a primeira auditoria de verdade só viria em doze meses.

Em qualquer um desses cenários, o trabalho é o mesmo. O que muda é a régua.

As quatro áreas que os auditores realmente investigam

Tire as marcas das consultorias e todo relatório de TDD cobre as mesmas quatro áreas. A PAA favorita “quais são os 4 componentes da due diligence” (financeiro, operacional, legal, RH) é a lista errada para software; aquela é a due diligence corporativa geral. A versão técnica se divide assim.

1. Código e arquitetura

O time de auditoria vai puxar o seu repositório e ler. Não tudo. Vão amostrar por diretório e por recência: o que foi alterado na última semana, o que parece ser a lógica de domínio central, o que o relatório de test coverage diz. Estão atrás de sinal em três coisas: o código é consistente (parece que um time escreveu, ou cinco contratados escreveram em três anos), a arquitetura é coerente (as fronteiras entre módulos fazem sentido, ou tudo virou um monolito gigante) e é mantenível (um engenheiro novo entra em um mês, ou o bus factor é um).

O que mata você aqui não é código feio. Auditores esperam código feio; software é sempre mais feio do que o fundador acha. O que mata é incoerência: três padrões diferentes para o mesmo problema, sem testes, sem documentação e sem histórico de versão que explique as decisões.

2. Infraestrutura e operações

Como o produto roda em produção, de verdade? Onde estão os servidores (uma conta de cloud real na AWS / GCP / Azure, ou o Linode pessoal de um fundador no qual mais ninguém consegue logar), como é o processo de deploy (um único comando num pipeline de CI, ou um desenvolvedor entrando via SSH numa máquina às 23h), e o que acontece quando algo quebra (uma escala de plantão com paging, ou uma mensagem no Slack que ninguém lê até o dia seguinte).

Auditores se importam com isso porque é a dimensão mais barata de checar se a empresa é real. Demo bonita com infra frágil é o padrão de falha mais comum que eles pegam.

3. Segurança e compliance

Alguém já rodou um scan de segurança de verdade? Os secrets estão em variáveis de ambiente ou colados no codebase? Existe audit log de quem acessou dado de cliente? Se a empresa vende para setor regulado, as alegações de SOC 2 / HIPAA / LGPD no site batem com a realidade da engenharia?

É a área onde resultados de TDD mais frequentemente matam deals diretamente. Um comprador convive com código bagunçado. Não convive com um achado de segurança que cria passivo regulatório que ele herdaria no fechamento.

4. Time e processo

O time de auditoria vai entrevistar os seus desenvolvedores individualmente. Vão perguntar: como vocês decidem o que construir, quem revisa código, o que acontece quando tem incidente em produção, e o que aconteceria se seu lead engineer saísse amanhã. As entrevistas são curtas, e os auditores procuram consistência entre o que o fundador diz e o que o time diz.

É aqui que o problema de bus factor aparece. Se as entrevistas mostram que uma pessoa é a única que entende um sistema crítico, essa frase única vai parar no relatório e os termos do deal começam a mexer.

Os sete red flags que reprovam deals

Em todas as TDDs que conduzimos com clientes, o relatório do auditor costuma girar em torno dos mesmos poucos problemas. Nenhum é exótico. Todos têm conserto se houver aviso.

O primeiro é bus factor de um. O lead engineer é a única pessoa que leu o codebase inteiro, e não existe documentação que sobreviva à saída dele. Esse é o achado mais comum e o que os investidores levam mais a sério, porque estão prestes a assinar um cheque que depende de uma pessoa que eles não contrataram.

O segundo é nenhum histórico de versionamento de relevância. O repositório existe, mas o primeiro commit é “initial commit” com 60.000 linhas despejadas de uma vez só. Não dá para ver quem decidiu o quê, nem quando. Em geral isso quer dizer que o codebase foi migrado (de um freelancer anterior, normalmente) e o histórico se perdeu. Auditores apontam porque significa que a empresa não consegue provar que o código é dela.

O terceiro é propriedade intelectual mal definida. O trabalho foi feito por um contratado, o contrato de desenvolvimento de software não tinha cláusula de work-for-hire ou de cessão de IP, e agora a empresa, tecnicamente, não é dona do código que ela vende. Esse único achado já matou deals em fase de due diligence.

O quarto é secrets no repositório. Chaves de API, senhas de banco, tokens de terceiros, tudo em texto puro no codebase. Auditores modernos rodam scan automático disso na primeira hora, e sempre acham algo.

O quinto é nenhuma observabilidade em produção. O time não sabe quando a aplicação está fora do ar. Sem uptime monitoring, sem error tracking, sem logs que alguém leia. Quando o auditor pergunta “com que frequência o app cai”, a resposta do time é “não sei, ninguém reclamou”.

O sexto é dependência excessiva de um único serviço de terceiros. O produto, na inspeção, é uma camada fina por cima da API de um fornecedor. Se esse fornecedor muda o preço, descontinua o endpoint ou cai, a empresa cai junto. A auditoria quantifica essa exposição e coloca um número em reais ao lado.

O sétimo é dívida técnica que o time não consegue descrever. Não a existência de dívida técnica em si (todo produto tem) mas a incapacidade de apontar para ela. Quando o lead engineer diz “o código está bem” mas o auditor encontra três migrações pela metade e um framework deprecado, o gap entre o que o time sabe e o que está lá vira o achado que mata o deal.

O playbook de quatro semanas de preparação para a TDD

Se você tem quatro semanas de aviso antes da auditoria começar (e a maioria dos fundadores tem, porque o lead investor ou o comprador sinaliza antes da engagement formal), os sete red flags acima são, quase todos, consertáveis. O playbook abaixo é o que rodamos com clientes que enfrentam a primeira TDD.

Semana um: propriedade e inventário

Confirme por escrito que toda linha de código no repositório foi escrita por um funcionário sob contrato de trabalho padrão ou por um contratado sob contrato de work-for-hire. Se o contrato de algum contratado não tinha cláusula de cessão de IP, envie uma carta de cessão de uma página e colete a assinatura antes da primeira call do auditor. É o conserto mais barato e o que tem o maior downside se ignorado.

Monte um inventário de todos os serviços externos dos quais o produto depende: cloud provider, banco de dados, autenticação, pagamentos, e-mail, analytics, monitoring. Uma linha por serviço: o que faz, quem paga, quem tem acesso admin. O auditor vai pedir essa lista no primeiro dia. Tê-la pronta sinaliza profissionalismo e poupa uma semana de e-mails de follow-up.

Semana dois: mate o bus factor

O problema de bus factor não dá para resolver inteiro em duas semanas, mas dá para reduzir de forma mensurável. Coloque seu único desenvolvedor em par com um segundo engenheiro (um júnior existente, um contratado de confiança, ou um estúdio parceiro) e faça os dois passarem a semana lendo o codebase juntos. Escreva à mão um documento de arquitetura de uma página: quais são os componentes principais, o que conversa com o quê, o que quebra se um serviço específico cair. Esse documento faz mais pelo seu placar de auditoria do que cem features novas.

Se você não tem um segundo engenheiro disponível e o deal é grande o suficiente para justificar, esta é a semana de chamar um technical advisor. Um engenheiro sênior que já passou por TDDs do lado auditado consegue ler o seu codebase, identificar o que vai ser flagrado e, em alguns casos, co-assinar decisões durante as entrevistas da auditoria.

Semana três: limpe os achados óbvios

Rode um scanner de secrets gratuito sobre o repositório (o scanner nativo do GitHub pega os casos comuns). Rotacione qualquer chave que aparecer. Mova toda credencial para variáveis de ambiente ou para um secrets store gerenciado. É um trabalho de dois dias que evita o achado automático mais comum de todos.

Suba observabilidade básica. Sentry para erros, um monitor de uptime simples (Better Stack, Pingdom, ou até uma conta gratuita do UptimeRobot) batendo na URL de produção a cada minuto. O ponto não é cobertura perfeita. O ponto é que, quando o auditor perguntar “como vocês sabem quando o app está fora do ar”, você tenha uma resposta que não seja um encolher de ombros.

Semana quatro: documentação e simulado

Escreva quatro documentos curtos: um README que explica como rodar o projeto localmente, um runbook de deploy que explica como uma release chega em produção, uma nota de resposta a incidente que explica o que fazer quando algo quebra e um overview de segurança de uma página listando quais dados você armazena e como eles são protegidos. Nenhum precisa ser longo. O time de auditoria checa se existem e se são honestos, não se são polidos.

Faça uma entrevista simulada com o seu desenvolvedor. Faça as perguntas que você sabe que o auditor vai fazer, na ordem em que vão ser feitas. Grave as respostas. A primeira vez que o seu único engenheiro ouvir “o que aconteceria se você saísse amanhã” não pode ser na frente do auditor.

O que acontece depois do relatório

O auditor entrega o relatório para o comprador, não para você. Na maioria dos casos o comprador compartilha pelo menos um resumo com o fundador durante a negociação, principalmente se os achados mexem nos termos do deal. Espere três desfechos possíveis.

Relatório limpo, deal fecha nos termos originais. Isso é raro para a primeira auditoria e vale comemorar quando acontece.

Relatório misto, deal fecha com condições. O comprador deixa o fechamento condicionado a remediação (contratar um segundo engenheiro em 60 dias, completar um SOC 2 em seis meses, transferir o IP de um contratado específico). É o resultado mais comum, e as condições são quase sempre negociáveis. O cronograma de remediação importa mais do que o achado em si.

Relatório ruim, deal renegocia ou morre. O preço cai, os termos apertam, ou o comprador desiste. Os achados que produzem esse desfecho estão quase sempre nas categorias de IP, segurança ou bus factor. São os sete red flags acima, na sua pior versão.

Os fundadores que passam melhor pela TDD são os que tratam a auditoria como uma avaliação paga e independente da saúde da engenharia, separada do deal. Os achados são úteis mesmo quando o deal não fecha. O relatório te diz o que consertar a seguir, no dinheiro de outra pessoa.

FAQ

O que é technical due diligence?

Technical due diligence é uma auditoria independente do software, da infraestrutura, da segurança e das práticas de engenharia de uma empresa, encomendada por um investidor ou comprador antes do aporte. É a contraparte técnica da due diligence financeira.

O que é technology due diligence?

A mesma coisa que technical due diligence. Os dois termos são intercambiáveis em contextos de software. Fora de software (construção, real estate, energia), “technical due diligence” pode significar um processo diferente, então confira o contexto.

Quais são os quatro componentes da due diligence?

Na due diligence corporativa geral, os quatro componentes são financeiro, operacional, legal e RH. Technical due diligence é uma frente à parte, com suas próprias quatro áreas: código e arquitetura, infraestrutura e operações, segurança e compliance, e time e processo.

Como me preparo para uma technical due diligence sendo um fundador não-técnico?

Rode o playbook de quatro semanas acima: confirme propriedade de IP por escrito, monte o inventário de serviços de terceiros, reduza bus factor colocando um segundo engenheiro em par com o codebase, limpe os achados automáticos (secrets, falta de observabilidade) e escreva os quatro documentos curtos que os auditores procuram (README, runbook de deploy, nota de incidente, overview de segurança). Se o deal é grande, chame um technical advisor para as entrevistas.

Quanto custa uma technical due diligence?

Quem paga é o comprador, não a empresa auditada. Engagements típicos vão de US$ 15 mil a US$ 75 mil, dependendo do escopo e da firma. Para o fundador, o custo indireto é o tempo do time consumido na janela da auditoria: em geral duas a quatro semanas de distração relevante para engenharia.

Quanto tempo leva uma technical due diligence?

De uma a quatro semanas de trabalho ativo para o time de auditoria. Da cadeira do fundador, planeje seis semanas de distração parcial: preparação, auditoria, resposta ao relatório.

Dá para recusar partes da auditoria?

Tecnicamente sim, na prática não. Qualquer coisa recusada vira red flag no relatório. O movimento certo é negociar o escopo antes com o comprador (algumas firmas exageram no escopo por default) e depois cooperar totalmente no que estiver dentro do escopo.