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?
A maioria das due diligences técnicas produz um documento que ninguém usa. Lista frameworks, conta testes, nota que a documentação podia ser melhor — e depois o negócio avança ou não por razões inteiramente alheias. Isso desperdiça uma oportunidade real de precificar risco.
Uma due diligence técnica útil responde a três perguntas em termos de negócio: esta tecnologia consegue sustentar o plano que está a financiar, quanto custará fechar as lacunas e que riscos podem destruir valor em vez de apenas o atrasar.
Para que serve realmente a due diligence técnica
Um investidor de capital de risco não compra uma base de código. Compra uma tese: esta equipa chegará àquela escala neste prazo. A tecnologia importa apenas onde torna essa tese mais ou menos provável.
| A tese diz | Logo a diligência tem de estabelecer |
|---|---|
| Crescimento ×10 de utilizadores em 24 meses | Onde a arquitetura parte e o custo de subir esse teto |
| Expansão para a UE | Se o tratamento de dados sobrevive ao RGPD e quanto custa uma versão conforme |
| Isto é um negócio de pagamentos | Integridade do livro-razão, idempotência, reconciliação — o que perde dinheiro a sério |
| A equipa sabe executar | Débito de entrega e bus factor, não a qualidade dos CVs |
| Tecnologia defensável | Se o fosso é engenharia real ou uma camada fina sobre a API de terceiros |
As cinco áreas que importam
1. Arquitetura e margem de escala
Todo o sistema tem um teto. A questão é onde está face ao plano e quanto custa levantá-lo. Um monólito que serve 100 000 utilizadores sem esforço não é uma constatação; um monólito com uma única base de dados master de escrita e um plano de crescimento para 10 milhões, é.
- Os pontos únicos de falha — e se a equipa sabe quais são
- A camada de dados — normalmente o teto real e o mais caro de mudar depois
- Se a carga alguma vez foi testada, ou se a escala é assumida
- Curva de custo cloud: a unit economics sobrevive a ×10, ou a infraestrutura come a margem?
2. Integridade do dinheiro e dos dados
Para qualquer empresa que toque em pagamentos, saldos ou dados regulados, esta é a área com maior custo de errar — e a mais saltada, porque inspecioná-la exige conhecimento de domínio.
- O saldo deriva de um livro-razão imutável, ou é um número mutável que o código pode sobrescrever?
- Idempotência nos caminhos de pagamento e webhook — uma repetição pode cobrar duas vezes?
- Dinheiro guardado como inteiros em unidades menores, nunca como float
- Reconciliação: uma discrepância seria detetada internamente, ou por um cliente?
3. Exposição de segurança e conformidade
Constatações de segurança só fazem sentido ligadas a uma consequência. «As dependências estão desatualizadas» é ruído. «Um endpoint não autenticado devolve registos de outros clientes» é uma cláusula contratual.
- Autorização aplicada no servidor a cada pedido, não escondida na interface
- Isolamento multi-tenant — de longe a constatação séria mais comum em SaaS B2B
- Gestão de segredos e se há credenciais no histórico do git
- Que dados regulados são guardados — e se sequer deveriam ser
- Distância à certificação exigida pelo go-to-market (SOC 2, ISO 27001, PCI DSS)
4. Capacidade de entrega
Isto prevê os próximos dois anos melhor do que a base de código atual. Uma base de código medíocre com forte disciplina de entrega melhora. Uma base de código elegante sem capacidade de lançar com segurança, não.
- Frequência de deploy e tempo de entrega de uma alteração pequena
- Se o rollback é rotina praticada ou teoria
- Cobertura de testes nos caminhos que importam (dinheiro, auth) em vez de uma percentagem global
- Deteção de incidentes: encontram os problemas antes dos clientes?
5. Risco de equipa e pessoa-chave
- Bus factor: quantas pessoas percebem os subsistemas críticos — se a resposta for uma, isso é risco de negócio
- Se o conhecimento existe fora das cabeças
- Dependência de prestadores sobre a PI central e se a cessão de PI está limpa
- Realismo do plano de contratação face ao roadmap financiado
Sinais de alerta, ordenados pelo que custam de facto
| Constatação | Gravidade | Porquê |
|---|---|---|
| Saldos mutáveis / sem livro-razão numa fintech | Nível do negócio | As perdas são ilimitadas e podem já ter ocorrido sem deteção |
| Acesso a dados entre tenants | Nível do negócio | Uma divulgação acaba com as vendas enterprise e aciona reguladores |
| Um único engenheiro detém todo o conhecimento crítico | Alta | A saída dele reinicia o roadmap |
| Sem automação de deploy | Alta | Limita o débito independentemente das contratações |
| Propriedade intelectual pouco clara vinda de prestadores | Alta | Jurídico, não técnico — mas mata saídas |
| Dependências desatualizadas | Baixa | Manutenção de rotina, avaliada em dias |
| Estilo de código inconsistente | Ruído | Ignorar |
O propósito da due diligence técnica não é encontrar uma razão para desistir. É saber com precisão o que se está a comprar, para que o preço e o plano o reflitam.
Como as constatações se traduzem em cláusulas
- Orçamento de remediação — quantificar as correções e financiá-las explicitamente na ronda em vez de as descobrir ao sexto mês
- Condições por marcos — libertação de tranche ligada a remediação específica (comum quando lacunas de conformidade bloqueiam o go-to-market)
- Ajuste de avaliação — onde a remediação é grande face à ronda
- Plano pós-fecho — um roadmap técnico a 90 dias acordado antes da transferência, não improvisado depois
Quanto tempo demora
| Profundidade | Duração | Quando usar |
|---|---|---|
| Triagem | 2-3 dias | Fase inicial, cheque pequeno, apenas verificação de sanidade |
| Padrão | 1-2 semanas | A maioria das rondas Series A / Series B |
| Profunda | 3-4 semanas | Fintech, healthtech, cheque grande ou alvo conhecido pela desarrumação |
Mais longo não é melhor. Passadas duas semanas, a maioria dos trabalhos produz detalhe em vez de decisões — a não ser que o domínio o exija mesmo, como pagamentos ou dados de saúde regulados.
Definir o âmbito antes de recolher documentos
A revisão deve refletir a tese de investimento. Defina questões, sistemas materiais e evidências antes de avaliar riscos.
- Ligar crescimento previsto a capacidade e custos observados.
- Separar declarações, testes confirmados e dados indisponíveis.
- Distinguir condições prévias ao fecho e plano financiado posterior.
Perguntas frequentes
Qual a diferença entre due diligence técnica e auditoria de código?
Uma auditoria de código examina a qualidade do código. A due diligence técnica examina se a tecnologia, a equipa e o processo de entrega conseguem sustentar um plano de negócio concreto — e quanto custam as lacunas. O código é uma de cinco entradas; arquitetura, segurança, capacidade de entrega e risco de pessoa-chave pesam habitualmente mais na decisão de investimento.
Quem paga a due diligence técnica?
Quase sempre o investidor, como parte dos custos da operação. Ocasionalmente um fundador encomenda-a antes da ronda para encontrar e corrigir problemas antes dos investidores — normalmente dinheiro bem gasto, porque constatações descobertas pelo outro lado custam muito mais em negociação do que em engenharia.
É preciso a cooperação da startup?
Sim. Uma diligência com significado precisa de acesso de leitura ao repositório, uma apresentação da arquitetura e uma conversa com os engenheiros. Um alvo que resiste a isto é, em si, uma constatação a registar.
Pode fazer-se due diligence técnica em poucos dias?
Uma passagem de triagem pode, e apanhará de forma fiável problemas ao nível da categoria: sem livro-razão numa empresa de pagamentos, sem automação de deploy, bus factor de um. Não lhe dirá quanto custa a remediação. Para uma ronda com preço, uma a duas semanas é o mínimo realista.
É possível continuar com acesso limitado?
Sim, com âmbito reduzido e limitações explícitas. Documente incertezas e peça as evidências em falta antes de depender da conclusão.
A fazer diligência a uma participada?
Entregamos constatações ordenadas por impacto no negócio, com custos de remediação que pode levar para a negociação — em uma a duas semanas.
Leitura complementar
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.
Auditoria técnica de MVP: o que verificamos nas primeiras 48 horas
A maioria das auditorias de MVP produz um documento. Uma útil produz decisões: o que está a arder, o que pode esperar e quanto custa corrigir.