Checklist de due diligence técnica para investidores

Um checklist só é útil se cada ponto tiver uma consequência associada. Este está ordenado pelo que realmente muda um negócio.

Use isto como documento de trabalho durante a diligência. Cada secção indica o que pedir, o que verificar e — o essencial — o que uma má resposta significa comercialmente. Os pontos estão ordenados por custo de errar, não por conveniência de verificação.

Antes de começar: o que pedir

• Acesso de leitura a todos os repositórios, incluindo infrastructure-as-code
• Histórico completo de commits (não um instantâneo achatado — o histórico revela quem construiu isto de facto e a que ritmo)
• Apresentação da arquitetura com o engenheiro que a construiu, 1-2 horas
• Acesso ao gestor de tarefas e a quaisquer registos de incidentes
• Lista de serviços de terceiros e respetivas condições contratuais
• Contratos de prestadores e documentos de cessão de PI

Secção 1 — Integridade do dinheiro e dos dados (nível do negócio)

Secção 2 — Segurança e multi-tenancy (nível do negócio)

• Autorização imposta no servidor em cada pedido, não escondendo elementos de interface
• Isolamento multi-tenant verificado por teste, não presumido da leitura do código
• Segredos num gestor, ausentes do histórico git (verifique o histórico, não apenas o HEAD)
• Que dados regulados são guardados, onde, e se é sequer necessário
• Distância à certificação que o go-to-market exige (SOC 2, ISO 27001, PCI DSS)

Secção 3 — Propriedade e jurídico (nível do negócio)

• Cessão de PI assinada por cada prestador e fundador
• Revisão de licenças open source — contaminação copyleft num produto proprietário
• Código copiado de empregadores anteriores (pergunte diretamente; acontece)
• Dependência de fornecedor: o que parte se um prestador-chave alterar preços ou encerrar

Secção 4 — Arquitetura e escala (elevado)

• Onde o sistema parte sob o crescimento do modelo financeiro — um número concreto, não garantias
• O teto da camada de dados: master único de escrita, consultas sem limite, cobertura de índices face aos padrões reais
• Isolamento de falhas: uma dependência lenta degenera em falha total?
• Curva de custo de infraestrutura a 10× — a unit economics sobrevive?
• Arquitetura ajustada ao tamanho da equipa (sistemas distribuídos com equipa pequena são um custo, não um mérito)

Secção 5 — Capacidade de entrega (elevado)

Secção 6 — Equipa e risco de pessoa-chave (elevado)

• Bus factor de cada subsistema crítico — se algum for 1, é risco do negócio e exige mitigação
• Se o conhecimento existe por escrito ou apenas em cabeças
• Exposição de retenção: quem seria catastrófico perder nos próximos 12 meses
• Realismo do plano de contratação que o roadmap assume

Pontuação: consequência, não gosto

Pontue cada constatação pelo que acontece se não for corrigida, e deixe isso guiar a resposta no negócio:

1. Nível do negócio — integridade do dinheiro, exposição de dados, PI pouco clara. Condição de fecho ou remediação financiada.
2. Elevado — teto de escala abaixo do plano, dependência de uma pessoa, sem segurança no deploy. Orçamentado no plano de 90 dias pós-fecho.
3. Médio — dívida cumulativa que atrasa a entrega. Registar e monitorizar.
4. Ruído — estilo, preferência de framework, volume de documentação. Excluir por completo do relatório.

Se uma constatação não puder ser ligada a dinheiro, tempo ou exposição jurídica, não pertence a um memorando de investimento.

O que exigir no relatório final

• Um resumo de uma página sobre o qual um sócio não técnico consiga agir
• Cada constatação com evidência que a equipa do alvo possa verificar autonomamente
• Estimativas de remediação em semanas-engenheiro, para se converterem em dinheiro
• Uma declaração explícita do que NÃO foi examinado — para ninguém presumir uma cobertura que não houve

Transformar a checklist num registo de decisão

Cada resposta deve ligar evidências a consequências para a operação. Acorde limites, acessos e perguntas antes de recolher documentos. Separe conclusões verificadas, declarações da gestão e provas em falta. Uma célula vazia não demonstra baixo risco.

O relatório distingue o examinado, o desconhecido e as consequências. Rever documentos não comprova, por si só, controlos eficazes em produção; revisão técnica não é certificação jurídica.

• Consultar o âmbito do serviço →