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.

A auditoria de código pré-investimento insere-se na due diligence técnica mais ampla e tem uma missão mais estreita: estabelecer o que existe de facto, se a propriedade está limpa e se aguenta o plano que está a ser financiado.

Mal enquadrada, produz uma lista de queixas de estilo. Bem enquadrada, produz duas ou três constatações que mudam o negócio.

Que acessos pedir

Peça-os antes de assinar o term sheet. Resistência nesta fase é informativa por si só.

• Acesso de leitura a todos os repositórios — incluindo infrastructure-as-code e scripts de deploy, onde muitas vezes se vê o verdadeiro estado das coisas
• Histórico completo de commits, não um instantâneo achatado: o histórico revela quem construiu realmente o sistema e a que velocidade avança
• Uma apresentação da arquitetura com o engenheiro que a construiu, uma a duas horas
• Acesso ao gestor de tarefas e, se existirem, aos registos de incidentes
• A lista de serviços de terceiros de que o produto depende

As oito perguntas a que a auditoria tem de responder

1. O código existente corresponde ao que foi descrito no pitch? (Demoware e integrações que são na verdade processos manuais são comuns.)
2. Quem o escreveu, e essas pessoas ainda cá estão?
3. A propriedade intelectual está limpa — prestadores com cessão, sem código copiado sem licença, sem contaminação de licença por dependências GPL num produto proprietário?
4. O que parte primeiro sob o plano de crescimento, e quanto custa mover esse teto?
5. Os dados de clientes estão isolados entre tenants, e a autorização é imposta no servidor?
6. Para tudo o que é financeiro: existe um livro-razão imutável, e todos os caminhos do dinheiro são idempotentes?
7. A equipa consegue fazer deploy com segurança — automação, rollback, monitorização?
8. Que parte do produto é genuinamente deles face a uma camada fina sobre fornecedores que podem alterar preços ou desaparecer?

Constatações que justificam uma cláusula

O que não merece a sua atenção

Auditores que faturam por constatação entregam-lhe uma lista longa. A maior parte não importa para uma decisão de investimento:

• Preferências de framework ou linguagem — toda a escolha tem críticos
• Estilo de código e formatação inconsistentes
• Percentagem global baixa de cobertura de testes, quando os caminhos de dinheiro e auth estão cobertos
• Dependências desatualizadas sem vulnerabilidade alcançável
• Documentação ausente — realmente comum, raramente decisiva, barata de corrigir

Se o relatório de auditoria não puder ser resumido em três frases ao seu comité de investimento, foi enquadrado como exercício de engenharia e não de investimento.

Como é um bom resultado

• Um resumo de uma página em linguagem de negócio, com uma posição de risco global clara
• Constatações ordenadas por consequência, cada uma com evidência que a equipa do alvo possa verificar
• Custo de remediação em semanas-engenheiro, para se converter em dinheiro
• Um plano técnico recomendado a 90 dias após o fecho
• Uma lista explícita do que NÃO foi examinado, para ninguém assumir uma cobertura que não houve

Especificar as evidências no pedido

O comprador deve conseguir seguir uma constatação até à origem e compreender o custo de agir.

1. Identificar repositório, commit, ambiente e data da revisão.
2. Pedir exemplos, percursos afetados e pressupostos de esforço.
3. Exigir exclusões e possibilidade de verificação posterior.

• due diligence técnica →
• due diligence técnica investidores →