O código que passa no pitch e reprova na due diligence

Conversei com founders que passaram por diligência técnica e viram o term sheet encolher. Não pelo produto, mas pela papelada, pela propriedade do código e pelo que ninguém tinha lido com olhos de comprador. Por que a hora de arrumar isso é muito antes da rodada.

Passei os últimos meses ouvindo a mesma cena contada de ângulos diferentes. Um founder fecha a narrativa da rodada, o investidor gosta, o term sheet aparece. Aí começa a diligência técnica, alguém de fora abre o repositório, e o número que estava no papel encolhe.

Em maio conversei com a fundadora de uma healthtech que tinha acabado de passar por isso. Series A encaminhada, um lead animado, e um consultor contratado pelo fundo para ler dois anos e meio de produto. O laudo voltou com treze páginas. A parte que doeu não era bug: era que ninguém no cap table sabia dizer de quem, legalmente, era o código escrito por um estúdio que ela contratou no primeiro ano e dispensou depois. O contrato era genérico. A cláusula de propriedade intelectual, também.

O produto dela funcionava bem. O que reprovou foi tudo o que ficava em volta: contrato, propriedade, um histórico que ninguém tinha lido com olhos de comprador.

Duas pessoas revisando um relatório, caneta sobre o gráfico: a diligência lê o que o pitch deixou de fora.

Escrevo sobre times de engenharia faz tempo, e essa é a lacuna que mais me chama atenção. O pitch é uma peça de venda: mostra a tração, o gráfico subindo, a demo que funciona. A diligência é o oposto do pitch. Ela não quer a história bonita, quer o que está embaixo. E o que está embaixo raramente foi construído pensando no dia em que alguém de fora abriria a tampa.

A diligência abre o que o pitch fecha

Diligência técnica não é caça a bug. Um consultor sério passa de três a cinco dias olhando um conjunto de coisas que o founder quase nunca mediu:

• Propriedade intelectual: quem assinou o quê, e se o código de terceiros virou seu de verdade.
• Concentração de conhecimento: quantas pessoas entendem o sistema, e o que acontece se a principal delas sai.
• Segurança básica: segredo commitado no repositório, dependência sem atualização, porta deixada aberta.
• Capacidade de entregar: quanto tempo leva de um commit até a produção, e quantas mãos precisam se envolver.

Nenhum desses itens aparece numa demo. Todos aparecem num laudo. E é por isso que a diligência costuma ser a primeira vez que o founder vê o próprio produto pela ótica de quem vai pagar por ele.

"A gente arruma antes da rodada" é a frase que não sobrevive

A reação mais comum, quando eu levanto isso numa conversa, é adiar. "Quando a rodada estiver perto, a gente organiza." Parece a ordem natural das coisas. Só que a diligência não espera você ficar pronto.

Documentar dois anos de decisão em três semanas não dá. Reescrever contrato de propriedade intelectual com um fornecedor que já saiu é uma negociação lenta, às vezes com alguém que nem atende mais. Testar o que nunca teve teste, num código que ninguém do time atual escreveu, é arqueologia. A diligência chega na pior janela possível: quando você tem menos tempo e mais a perder. Quem chega nela improvisando entrega o laudo de bandeja, como argumento de desconto para o outro lado da mesa.

O contraponto é sem brilho, e é o que funciona: um time que trabalha, desde o começo, como se a tampa pudesse ser aberta a qualquer momento. Os squads que a gente acompanha na Revin operam assim por padrão, com rodada à vista ou nenhuma no horizonte. Código que passa em diligência é o mesmo que não quebra em produção, e a disciplina que garante um é a que garante o outro.

Se você desconfia que o seu código não sobreviveria a uma leitura de fora, um Diagnostic Sprint abre a tampa antes do investidor. Vale conhecer.

O que costuma aparecer no laudo

Li mais laudos de diligência do que gostaria, e alguns padrões se repetem. Segredo de produção versionado em texto puro no histórico do Git, de onde ele nunca some de verdade. Uma pessoa só entendendo o núcleo do sistema, sem nada escrito. Bibliotecas duas ou três versões principais atrás, com falha conhecida e pública. Um deploy que depende de um passo manual morando na cabeça de alguém.

Numa amostra de projetos que chegaram até mim pedindo segunda opinião no último ano, algo como dois terços tinha pelo menos um segredo exposto no repositório. Esse número pode estar enviesado, admito: ninguém me procura pra contar a diligência que correu bem. Mas mesmo cortando pela metade, é alto demais para um problema que custa um dia pra resolver e uma rodada pra descobrir tarde.

Um time em volta de um mesmo laptop: código que passa numa leitura de fora é feito por quem já esperava por ela.

O laudo não pergunta quem escreveu

Aqui mora um mal-entendido que atrapalha o founder. Diligência ruim não é sinônimo de engenharia terceirizada. Já vi time interno deixar o repositório num estado que envergonharia qualquer fornecedor, e já vi squad externo entregar um código que o consultor do fundo elogiou por escrito. A pergunta que importa é uma só: o código foi escrito com disciplina, ou foi remendo?

O remendo tem assinatura reconhecível: o freelancer que apareceu por três meses e sumiu, o estúdio que entregou o MVP e devolveu um contrato genérico, a agência que faturou por hora sem deixar um teste. Cada um resolveu o problema da semana e nenhum pensou no laudo que viria dois anos depois. Um squad sênior gerenciado pensa, porque a mesma disciplina que faz um teste passar é a que faz uma cláusula de PI ser assinada e um segredo nunca entrar no repositório.

A pergunta de quem é o dono do código, aliás, merece um artigo só dela, e tem um aqui.

Voltando àquela fundadora

A healthtech fechou a rodada, mas menor do que valia, e com uma parte do dinheiro carimbada para arrumar o que a diligência apontou. Ela me deixou uma frase que eu repito desde então: "paguei duas vezes pelo mesmo código: uma pra escrever, outra pra provar que era meu".

Não escrevo isso pra assustar quem vai levantar capital. Escrevo porque a diligência é só o momento em que a conta chega; o gasto foi feito lá atrás, na escolha de quem construiu e de como. Se você quer que a leitura de fora seja um carimbo e não um susto, a hora de tratar disso é agora, muito antes do term sheet.

Quer uma leitura honesta do estado real do seu código antes que um fundo faça a dele? Fale com a Revin.