O que os VC procuram realmente na due diligence técnica

·8 min de leitura

Os investidores não estão a avaliar o seu código. Estão a precificar o risco de a tecnologia travar o plano que estão a financiar — e os fundadores que percebem isso preparam-se de forma muito diferente.

Os fundadores que se preparam para uma due diligence técnica polem muitas vezes o que não interessa — arrumar código, escrever documentação que ninguém pediu, preocupar-se com a escolha de framework. Os investidores fazem uma pergunta completamente diferente: o que pode correr mal do lado da tecnologia que impeça esta empresa de atingir os marcos do plano?

As quatro coisas que são realmente avaliadas

1. Escala até ao plano (não até ao infinito)

Ninguém espera que uma empresa em Série A tenha a arquitetura da Google. A pergunta é mais estreita: o sistema sobrevive ao crescimento concreto do modelo e, se não, quanto custa levantar esse teto? Uma resposta clara e orçamentada é um sinal forte. «Deve dar» não é.

2. Risco de pessoa-chave

Frequentemente a constatação mais decisiva, e aquela que os fundadores menos esperam. Se um único engenheiro detém todo o conhecimento crítico, o investimento carrega um risco que nada tem que ver com qualidade de código. Os investidores sondam isto diretamente: quem mais conseguiria operar este sistema na próxima semana se essa pessoa saísse?

3. Se a tecnologia é mesmo vossa

  • Trabalho de prestadores sem cessão de PI assinada — um problema jurídico capaz de atrasar ou matar um fecho
  • Contaminação de licença open source num produto proprietário
  • Dependência crítica de um fornecedor que pode alterar preços, restringir ou desaparecer
  • Que parte da «tecnologia proprietária» é uma camada fina sobre a API de terceiros

4. Capacidade de entrega

Isto prevê os próximos dois anos melhor do que o estado atual da base de código. Os investidores olham para a frequência de deploy, como as alterações chegam a produção, se os incidentes são detetados internamente, e se a equipa aguenta as contratações que o plano assume.

Como se preparar (nas quatro semanas anteriores)

  1. Escreva um registo honesto de riscos técnicos — o que é fraco, o que bloqueia, quanto custa remediar. Apresentá-lo por iniciativa própria lê-se como competência; ser apanhado a escondê-lo lê-se ao contrário.
  2. Corrija primeiro tudo o que é da categoria dinheiro e dados — são essas as constatações que se tornam condições.
  3. Feche lacunas de PI: cessões assinadas de todos os prestadores, revisão de licenças das dependências.
  4. Reduza visivelmente o bus factor — junte outra pessoa ao sistema crítico, escreva o registo de decisões de arquitetura.
  5. Prepare uma apresentação clara da arquitetura: o que é, porquê, onde parte, qual é o plano.

Como as constatações se traduzem em termos

ConstataçãoResultado típico
O dinheiro pode estar errado em silêncio (sem livro-razão)Remediação financiada na ronda; por vezes em tranches
Exposição de dados entre tenantsCondição de fecho — corrigir antes da libertação de fundos
PI pouco clara vinda de prestadoresRegularização jurídica exigida antes do fecho
Bus factor de umPacote de retenção, ou compromisso de contratação no plano
Deploy manual, sem rollbackOrçamentado no plano de 90 dias pós-fecho
Dependências envelhecidas, documentação escassaRegistado, sem consequência
Os investidores não esperam um sistema perfeito. Esperam um fundador que saiba com precisão que partes são imperfeitas e quanto custa corrigi-las.

Ligar cada constatação a uma decisão

Explique que pressupostos continuam válidos e o que muda o plano. Mostre incerteza junto do esforço de correção.

  1. Indicar hipótese comercial e evidências examinadas.
  2. Descrever consequência, incerteza e dependências da reparação.
  3. Separar condição de fecho, verba prevista e risco aceite.

Perguntas frequentes

Quanto tempo demora a due diligence técnica de um investidor?

Tipicamente uma a duas semanas para uma Série A, mais para fintech, healthtech ou sistemas invulgarmente grandes. Envolve normalmente acesso ao repositório, uma apresentação da arquitetura e entrevistas com a equipa de engenharia.

Os fundadores devem fazer a sua própria auditoria técnica antes de levantar?

Muitas vezes sim. As constatações que você mesmo traz à superfície tornam-se um plano de remediação que controla; as mesmas constatações trazidas pelo consultor do investidor tornam-se uma posição negocial contra si. O custo de uma auditoria pré-ronda é pequeno face ao impacto na avaliação que pode evitar.

Código desarrumado pode matar a nossa ronda?

Raramente por si só. Os negócios são afetados por constatações com consequência — integridade do dinheiro, exposição de segurança, propriedade intelectual pouco clara e risco de pessoa-chave. Os investidores já viram as imperfeições de todas as bases de código; o que os preocupa é uma equipa incapaz de descrever com rigor os seus próprios riscos.

Uma pontuação técnica única é suficiente?

Não. Resume, mas oculta âmbito e incerteza. Inclua constatações materiais, provas indisponíveis e pressupostos das estimativas.

Vai levantar em breve?

Fazemos a diligência antes do seu investidor — para que as constatações cheguem com o seu plano de remediação em anexo.

Technical Due Diligence →

Leitura complementar

Due diligence técnica para investidores: o guia completo

A due diligence técnica não é uma revisão de código. É a resposta a uma pergunta: quanto custará levar esta tecnologia até onde a tese de investimento precisa que ela esteja?

Auditoria de código pré-investimento: o que pedir antes de transferir

Está prestes a comprar uma parte de um ativo que não inspecionou. A auditoria de código é a inspeção — mas só se for enquadrada para responder a perguntas de investimento e não de engenharia.