A due diligence técnica muda o preço

A due diligence técnica não é um concurso de qualidade de código. O comprador quer saber quais fatos técnicos alteram o fluxo de caixa futuro, ameaçam a propriedade do ativo, atrasam a integração ou deixam a empresa dependente de uma pessoa que pode sair após o fechamento. Abstrações limpas são agradáveis. Entregas previsíveis, direitos comprováveis e risco operacional controlado afetam a transação.

Já vi compradores passarem dias discutindo convenções de nomes enquanto um processamento noturno de liquidação não tinha responsável, build repetível nem teste que provasse que o resultado de ontem correspondia ao de hoje. Isso está invertido. Uma análise útil acompanha as consequências comerciais pelo código, pelo caminho de implantação, pelas pessoas e pelos contratos, e então declara como cada descoberta deve afetar preço ou termos.

O comprador precifica a incerteza, não o estilo

O comprador usa a due diligence técnica para transformar incógnitas em um plano com custos. A base de código é evidência, mas apenas uma parte. Histórico de repositórios, sistemas de build, telemetria de produção, registros de incidentes, manifestos de dependências, diagramas de arquitetura, controles de acesso e entrevistas mostram se o software continuará gerando receita sob nova propriedade.

A primeira distinção que costuma desaparecer é entre defeito e risco da transação. Uma consulta lenta com correção clara, responsável e raio de impacto limitado é um defeito. Um mecanismo de faturamento sem documentação, entendido por um único contratado, é risco da transação, mesmo que opere há anos sem incidente. O primeiro cria um ticket de engenharia. O segundo pode justificar retenção, condição de fechamento, acordo de transição ou avaliação menor, pois tanto a probabilidade de falha quanto o custo de recuperação são difíceis de limitar.

Os revisores devem ligar cada descoberta material a um mecanismo econômico. Exige correção imediata? Bloqueia uma combinação planejada de produtos? Pode interromper receita, violar contrato com cliente ou impedir o comprador de operar o ativo? O comprador precisa reter um funcionário específico ou comprar uma licença comercial? Sem essa ponte, a descoberta é observação, não diligência.

Rótulos de severidade escondem essa lógica. Duas descobertas classificadas como «altas» podem ter efeitos diferentes. Um endpoint administrativo público pode exigir ação antes do fechamento. Um banco de dados no limite da capacidade pode justificar um projeto financiado depois. Uma contribuição de código contestada pode exigir indenização. Declare a consequência e o controle disponível antes de escolher uma cor.

O comprador também precisa de um nível de confiança. Se os revisores não conseguem executar o sistema, acessar dados semelhantes aos de produção ou entrevistar o operador, não devem marcar silenciosamente a área como limpa. Devem registrar a lacuna de evidência como risco próprio. Evidência ausente costuma mudar mais os termos do que um defeito conhecido, porque ninguém consegue precificar honestamente o limite superior.

O acesso ao repositório deve provar o que está sendo comprado

O acesso ao repositório deve estabelecer completude, histórico e procedência antes que alguém examine a arquitetura. Um repositório de aplicação bem cuidado pode distrair de scripts de implantação ausentes, geradores de relatórios, firmware, jobs de banco ou um diretório separado copiado manualmente para servidores de produção. A transação cobre um sistema em operação no sentido amplo, não o primeiro repositório que o vendedor abriu.

Peça um inventário que relacione cada componente de produção com repositório, caminho de build, responsável pela implantação, runtime, armazenamento de dados e ambiente. Compare-o com contas de nuvem, agendadores, registros de pacotes, sistemas de arquivos dos servidores, lojas móveis, registros DNS e faturas de fornecedores. Se um executável gera receita mas não tem localização de código-fonte, o comprador pode estar adquirindo um binário que não consegue reproduzir.

O histórico importa porque um snapshot atual não mostra autoria nem concentração de desenvolvimento. Obtenha todo o histórico de commits, tags, branches necessárias para versões suportadas, submódulos, armazenamento de arquivos grandes e artefatos de build não reproduzíveis. Verifique se uma importação de última hora achatou anos de histórico. Pode ser inocente, mas impede uma análise confiável dos contribuidores e dificulta testar declarações de propriedade intelectual.

Uma sequência curta de triagem oferece um primeiro mapa. Execute-a em uma cópia isolada, revise cada comando antes e adapte os caminhos ao repositório:

git rev-parse --is-shallow-repository
git shortlog -sne --all
git log --all --format='%aN <%aE>' | sort | uniq -c | sort -nr | head -20
git ls-files | sed 's|/.*||' | sort | uniq -c | sort -nr | head -30
find . -maxdepth 4 -type f \( -name 'package-lock.json' -o -name 'go.sum' -o -name 'Cargo.lock' -o -name 'pom.xml' -o -name '*.csproj' \) -print
find . -maxdepth 4 -type f \( -iname 'license*' -o -iname 'notice*' -o -iname 'copying*' \) -print

A saída esperada não é aprovação ou reprovação. É um conjunto de pistas: se o histórico é raso, quais identidades dominam os commits, onde o código se concentra, quais ecossistemas de dependências existem e onde ficam os avisos de licença. Depois vêm a consolidação de aliases e a exclusão de bots. Nunca equipare quantidade de commits a propriedade ou habilidade. Mudanças geradas, importações, programação em dupla e rebases distorcem os números.

Por fim, reproduza uma versão suportada a partir de um commit documentado. Registre a cadeia de ferramentas, segredos necessários, artefatos externos, duração do build e checksums quando uma saída determinística for esperada. Um build que só funciona no notebook de um funcionário não é reproduzível apenas porque esse notebook está disponível durante a diligência.

O risco de pessoa-chave aparece nas decisões e operações

O risco de pessoa-chave existe quando a ausência de alguém pode interromper uma mudança material, recuperação ou processo comercial. A concentração de commits é uma pista, não o diagnóstico. O risco se esconde em decisões não documentadas, credenciais privadas, rituais manuais de produção, relações com fornecedores, correções de dados e autoridade para aprovar uma versão.

Comece pelos caminhos críticos: captura de pedidos, liquidação, faturamento, fechamento mensal, relatórios regulatórios, atendimento e acesso de clientes. Para cada um, pergunte quem consegue explicar, alterar, implantar e recuperar. Quatro nomes só são melhores que um se essas pessoas puderem agir de modo independente. Uma equipe que sempre chama o ex-fundador antes de tocar uma regra de preços ainda tem um único responsável efetivo.

Teste o conhecimento com trabalho, não apenas entrevistas. Peça a um segundo engenheiro para rastrear uma transação de produção, encontrar a regra aplicável, fazer uma mudança inofensiva fora de produção, executar os testes e descrever o rollback. Peça ao substituto de plantão para restaurar um backup representativo e diagnosticar um job agendado com falha. O observador deve anotar onde a pessoa precisa de informação não documentada ou da permissão de outro funcionário.

O caso incômodo é o fundador competente que pretende sair. Compradores às vezes aceitam uma promessa vaga de disponibilidade porque substituir conhecimento profundo parece indelicado ou caro. Essa promessa é fraca. Defina uma entrega de transição: runbooks nomeados, explicações gravadas, transferência de credenciais, implantações em dupla, exercício de incidente e aceitação por quem operará o sistema. Se a dependência for material, vincule a conclusão a uma condição de fechamento, contrato de consultoria ou pacote de retenção.

Não confunda tecnologia antiga com risco de especialista único. Um ambiente COBOL bem gerido, com vários operadores, comportamento de produção registrado, builds automatizados e recuperação ensaiada, pode ser mais seguro que um serviço moderno escrito no ano passado por um contratado que já saiu. A idade da tecnologia afeta contratação e custo de mudança. Conhecimento concentrado afeta continuidade. Eles coincidem em alguns sistemas, mas evidências e remédios são diferentes.

O preço muda quando o comprador precisa financiar pessoal duplicado, reter alguém em termos excepcionais, adiar a integração ou aceitar exposição a indisponibilidade que não pode segurar. Se um plano prático de transferência fechar a lacuna antes do fechamento, transforme-o em condição. Se o vendedor não consegue transferir o conhecimento porque ninguém mais o tem, trate a correção como parte do caso de investimento, não como tarefa de documentação.

A exposição a licenças começa pela procedência

A análise de licenças deve responder se o vendedor tem o direito de transferir e operar cada parte material do produto. Um scanner de dependências ajuda, mas não prova cessão de funcionários, propriedade de contratados, trechos copiados, componentes comprados, direitos sobre dados de treinamento ou termos ligados a código recebido de parceiros. Essas são questões de procedência.

Crie uma lista de materiais de software a partir de manifestos, lockfiles, diretórios vendor, imagens de contêiner, clientes gerados, pacotes móveis e pacotes de sistema operacional distribuídos com o produto. Compare-a ao que realmente chega aos clientes ou à produção. A documentação do grafo de dependências do GitHub diz que sua análise estática processa manifestos e lockfiles suportados. Esse limite importa: um JavaScript antigo colado em um diretório vendor ou um binário guardado em uma pasta de release pode ficar fora do grafo.

Use identificadores SPDX para normalizar descobertas. A especificação SPDX permite expressões com AND, OR e WITH, preservando distinções destruídas por uma coluna chamada «licença». GPL-2.0-only OR MIT oferece escolha; LGPL-2.1-only AND BSD-2-Clause diz que ambas se aplicam ao conjunto descrito. Um revisor que reduza as duas a uma lista de nomes pode recomendar a correção errada.

O scanner produz alegações que precisam de decisão. Para cada resultado material, registre componente e versão, como entra no produto, se foi modificado, onde é distribuído ou hospedado, licença detectada e concluída, avisos ou ofertas de fonte exigidos, responsável e evidência. O jurídico interpreta a lei. A engenharia prova uso e possibilidade de substituição. Nenhuma disciplina termina sozinha.

Trate a propriedade do código próprio com o mesmo cuidado. Compare contribuidores com datas de emprego, acordos de cessão de invenções, escopos de trabalho de contratados, anexos de aquisições e código importado de projetos anteriores. Examine commits com e-mails pessoais, domínios externos, estagiários, agências e fundadores antes da constituição. Uma garantia assinada no contrato de compra ajuda, mas não elimina a reivindicação de um terceiro.

O preço muda quando um componente não pode ser distribuído legalmente no modelo pretendido, sua substituição atrasaria o plano ou a propriedade permanece contestável. Lacunas menores costumam caber em um cronograma de fechamento, limpeza de avisos, indenização dirigida ou escrow. Não chame toda dependência copyleft de fatal. Distribuição, linkagem, modificação e o texto real da licença determinam obrigações; rótulos gerais não substituem a análise jurídica.

Uma suíte de testes só é evidência quando pode falhar

O estado dos testes importa porque o comprador mudará o sistema depois do fechamento. Contagens de arquivos e percentuais de cobertura dizem pouco sobre detectar regressões comerciais. Mil asserções em torno do acesso a dados não protegem um cálculo de liquidação se ninguém codificou o resultado esperado.

Execute a suíte em ambiente limpo com o comando documentado. Anote tempo de configuração, serviços externos, tratamento de segredos, duração, repetições por instabilidade, testes ignorados e falhas no branch padrão. Depois introduza uma pequena falha controlada em uma regra importante e confirme que um teste pertinente falha pelo motivo esperado. Reverta de imediato. Essa mutação costuma informar mais que um relatório de cobertura porque testa se o teste sabe contestar.

Separe quatro formas de evidência. Testes unitários protegem regras locais. Testes de integração provam que componentes concordam em protocolos e persistência. Testes ponta a ponta exercitam caminhos implantados, mas cobrem poucas variações. Comparação ou replay de produção mostra se a substituição preserva o comportamento observado. Nenhum substitui os outros. Uma suíte de navegador verde não valida um cálculo anual, e alta cobertura unitária não prova que migrações funcionam.

Leia o histórico de falhas da integração contínua. Um branch padrão vermelho que todos ignoram mostra falha de controle, mesmo quando cada erro tem explicação. O mesmo vale para uma suíte que só passa após tentativas. Pergunte como a equipe isola testes instáveis, quem pode ignorar verificações, se branches protegidas exigem resultados e como hotfixes diferem do caminho normal.

Os dados de teste criam risco próprio. Determine se fixtures contêm dados de clientes ou funcionários, como são mascarados, quem acessa e se obrigações de exclusão alcançam backups e cópias de desenvolvedores. O comprador não quer descobrir durante a integração que o ambiente mais rápido depende de um dump de produção sem controle.

Traduza o resultado em custo de mudança. Testes fracos obrigam a lançar mais devagar, verificar mais manualmente, aceitar mais incidentes ou investir cedo em testes de caracterização. Se o roteiro supõe integração rápida ou reescrita da plataforma, a falta de evidência comportamental pode mudar o preço porque não há forma barata de provar que o software alterado continua produzindo os mesmos resultados.

A operabilidade revela a conta oculta de engenharia

A operabilidade mostra quanto trabalho o software consome depois da implantação. Compradores devem examinar releases, observabilidade, restauração de backups, tratamento de incidentes, capacidade e reparos rotineiros de dados. Um produto pode parecer estável porque duas pessoas experientes evitam discretamente falhas visíveis todos os dias. Esse trabalho pertence ao modelo de custos.

Observe uma implantação normal e, se o cronograma permitir, um rollback de emergência. Identifique barreiras manuais, contas compartilhadas, comandos não documentados, servidores mutáveis e aprovações que só existem no chat. Confirme que a versão implantada pode ser rastreada até o código e que a equipe sabe quais migrações foram executadas. Um documento que descreve o caminho ideal e não o real é decoração.

Peça registros de incidentes e alertas de amostra, depois siga um caso recente da detecção à correção. Evidências úteis incluem horários, responsabilidade pelo alerta, logs, métricas, comunicação com clientes, trabalho posterior e prova de que a correção chegou à produção. A ausência de incidentes registrados pode significar ótima confiabilidade. Também pode significar que a empresa não registra incidentes. Telemetria e entrevistas distinguem os casos.

Backups merecem um teste de restauração. Uma captura de backups agendados prova que um job rodou, não que o negócio consegue se recuperar. Restaure dados representativos em ambiente isolado, verifique integridade, meça o processo e identifique credenciais ou acesso de fornecedor necessários numa falha real. Compare o resultado com promessas a clientes e objetivos internos sem inventar precisão que nunca foi medida.

Correções manuais de dados são outro ponto cego. Procure em tickets, scripts, notebooks e histórico de shell ajustes em saldos, pedidos, permissões ou relatórios. Determine quem aprova, se as mudanças são registradas e se o defeito original permanece. Correções frequentes e seguras podem ser operação normal. Escritas não revisadas em produção criam exposição financeira e de auditoria.

Esse trabalho muda o preço quando trabalho recorrente faltou na narrativa de margem, capacidade precisa vir antes do crescimento, a recuperação não atende contratos ou a integração remove uma dependência assumida pelo sistema. Muda os termos quando o vendedor pode fazer um teste de restauração, transferir contas ou corrigir um controle perigoso antes do fechamento.

A arquitetura importa onde limita a tese da transação

A análise de arquitetura deve testar o uso pretendido pelo comprador, não premiar diagramas da moda. Um monólito pode ser uma compra sensata se for implantado de forma previsível e suportar o plano de crescimento. Um conjunto de serviços pode ser passivo se a responsabilidade for difusa, as chamadas formarem ciclos e cada release exigir mudanças coordenadas.

Mapeie capacidades comerciais para módulos, armazenamentos, filas, interfaces externas e unidades de implantação. Coloque a tese da transação sobre o mapa. Se o comprador pretende combinar identidades, o sistema separa locatários e reconcilia usuários? Para expansão internacional, onde estão suposições de moeda, impostos, fuso e localização? Se a economia depende de consolidar infraestrutura, quais serviços proprietários ou limites de rede resistem?

Procure restrições com evidências: runtimes sem suporte, avisos de fim de vida, tabelas sem limite, chamadas síncronas em caminhos de receita, propriedade compartilhada de banco, suposições de ambiente fixas no código e janelas batch perto do limite. Não converta idade em severidade automaticamente. Um runtime antigo atrás de interface estável pode ter substituição limitada. Um framework novo com dependências abandonadas pode ser mais difícil.

Os dados costumam ser a parte difícil. Examine propriedade do esquema, histórico de migração, retenção, identificadores, duplicatas, trilhas de auditoria e jobs de reconciliação. Pergunte como falhas parciais são reparadas e como consumidores posteriores recebem correções. Se dois produtos usam a mesma palavra para entidades diferentes, um gateway de API não resolve o conflito semântico.

Estime a mudança por partes de comportamento observável, não linhas de código. Escolha um caminho comercial, liste entradas, saídas e dependências e peça à equipe que explique como o moveria ou substituiria. A resposta mostra se os limites existem na prática. Também expõe trabalho oculto em procedures, clientes desktop, planilhas e jobs que os diagramas omitem.

Uma estimativa de reescrita não é dedução automática do preço. Torna-se uma quando o retorno depende da reescrita, o sistema bloqueia outra mudança necessária ou mantê-lo impõe custo ausente da avaliação. Caso contrário, um sistema antiquado mas controlado merece orçamento de modernização, não desconto de pânico.

Descobertas de segurança precisam de caminho e remédio

Uma descoberta de segurança afeta a transação quando cria caminho plausível para dano material ou mostra um controle que o comprador terá de fornecer. A severidade do scanner é ponto de partida. Exposição, privilégios, dados acessíveis, mitigações, requisitos de exploração e detecção determinam o risco comercial.

Siga a identidade desde o login do cliente até o acesso administrativo e credenciais de máquina. Revise ciclo de contas, papéis privilegiados, autenticação multifator quando suportada, responsabilidade por contas de serviço, armazenamento de segredos e acesso de emergência. Amostre contas reais, em vez de aceitar uma política. Ex-funcionários com credenciais ativas e senhas compartilhadas são fatos; uma frase genérica sobre acesso fraco não é.

Para vulnerabilidades, prove se o componente afetado está implantado e acessível. Registre versão, caminho da chamada, controle da entrada, limite de privilégio, dados em risco, controle compensatório e caminho de atualização ou remoção. Uma dependência em ferramenta de teste merece tratamento diferente da mesma biblioteca em serviço público. Ambas exigem decisão, mas a evidência define prioridade.

Revise como a empresa recebe, classifica, corrige e divulga relatórios. Inspecione patches recentes e o caminho do relato ao release. Se houve evento de segurança, compare registros técnicos com avisos a clientes, declarações de seguro, correspondência regulatória e divulgações da transação. Uma inconsistência pode importar mais que a falha original porque questiona declarações da gestão.

Clientes regulados acrescentam requisitos, mas apoiar um ambiente regulado não é ter certificação. Peça o controle contratual exato, limite do sistema, evidência e responsável. Não transforme escolha de hospedagem ou relatório de invasão em afirmação ampla de conformidade. O comprador herda promessas de contratos assinados, não adjetivos de uma apresentação comercial.

Comprometimento imediato, eventos não divulgados ou falhas sistêmicas de acesso podem bloquear o fechamento. Vulnerabilidades corrigíveis normalmente entram num cronograma com responsável e prova. A distinção preserva credibilidade: se todo pacote antigo ameaça a transação, ninguém ouvirá quando uma descoberta realmente deveria.

As descobertas mudam o preço por poucos mecanismos

Um problema técnico altera a economia por custo de correção, benefício atrasado, custo recorrente, receita perdida ou interrompida, passivo contingente ou maior chance de fracasso da tese. Os revisores devem evitar falsa precisão, mas mostrar mecanismo e premissas.

Use um registro de decisão para cada descoberta material. Esta é a forma mínima que espero:

Finding: Settlement rules have one effective owner
Evidence: Only one engineer can trace, change, deploy, and recover the nightly job
Business path: Customer settlement and finance reconciliation
Deal effect: Integration cannot safely begin on the planned date
Control before close: Backup owner completes a change and recovery exercise
Residual action: Add characterization tests around recorded settlement cases
Owner and evidence date: [named person] / [date]
Term response: Closing condition or funded retention agreement
Price response: Cost only if the control cannot be completed
Confidence: Medium, recovery was observed but a live release was not

Esse registro separa fato de resposta e evita contagem dupla. Se a avaliação já inclui modernização, não desconte o mesmo trabalho novamente, salvo se a análise ampliar o escopo ou o risco. Se um pacote de retenção controla o risco do único especialista, não precifique também o cenário completo de parada como certo. Mostre o risco residual depois do controle.

Mecanismos diferentes pedem ferramentas diferentes. Uma correção conhecida e limitada pode reduzir preço ou aumentar orçamento. Um fato que o vendedor pode corrigir pode virar condição de fechamento. Um risco específico de propriedade ou divulgação pode exigir declaração, indenização, escrow ou retenção desenhada pelo jurídico. Investimento futuro incerto pode afetar earn-outs ou o caso de investimento, embora um earn-out mal desenhado crie incentivos ruins.

Classifique descobertas por decisão, não pela severidade do scanner. O conselho precisa saber o que impede a assinatura, o que deve ocorrer antes do fechamento, o que muda valor, o que entra no primeiro plano e o que o comprador aceita. Os detalhes técnicos ficam abaixo, mas um catálogo de cem páginas não substitui essas escolhas.

A qualidade das evidências merece sua própria conclusão

O relatório deve dizer o que os revisores observaram, receberam e reproduziram e o que ficou indisponível. A qualidade da evidência controla a confiança em cada conclusão técnica. Um diagrama fornecido pelo vendedor e uma implantação observada não merecem o mesmo peso.

Use rótulos simples: reproduzido, observado, documentado, relatado e indisponível. Reproduzido significa que o revisor executou o procedimento e obteve o resultado. Observado significa que a equipe o fez diante dele. Documentado significa que um artefato apoia a alegação. Relatado significa que alguém afirmou. Os rótulos não acusam desonestidade; mostram a incerteza restante.

A amostragem também precisa de limites. Se os revisores inspecionam três de quarenta serviços, diga por que foram escolhidos e quais riscos ficaram fora. Escolha caminhos de receita, componentes privilegiados, mudanças recentes e problemas conhecidos antes de repositórios arrumados. O acaso pode complementar o julgamento, mas costuma perder os sistemas capazes de prejudicar a transação.

Restrições de acesso são descobertas quando impedem uma conclusão material. Um banco de produção pode ficar fora com razão, mas o vendedor costuma poder fornecer exportações de esquema, amostras mascaradas, planos de consulta, tráfego gravado ou sessão observada. Sem substituto, registre a pergunta e o possível efeito. Não transforme «não testado» em «nenhum problema encontrado».

A apresentação final deve ser compreensível para engenharia, finanças, jurídico e liderança da transação. Cada público precisa dos mesmos fatos em resolução diferente. Mantenha uma única fonte para evidências e decisões, para que uma mudança tardia não deixe slides, planilhas e anexos contraditórios.

O primeiro plano operacional começa antes da assinatura

Uma boa due diligence técnica deixa ao comprador um plano executável de propriedade, mesmo que a transação não feche. O resultado mais útil é uma lista curta de decisões controladas: qual risco muda os termos, qual evidência falta, quem responde por cada ação anterior e qual trabalho entra no plano financiado depois.

Ordene o trabalho por dependência e consequência. Proteja o acesso administrativo antes de mudar a implantação. Capture comportamento de produção antes de substituir regras. Transfira conhecimento de fornecedores e operadores antes do fim dos avisos. Ensaie a restauração antes de consolidar infraestrutura. São controles específicos, não um backlog genérico.

Código legado costuma concentrar conhecimento raro, testes fracos, procedência mista e comportamento espalhado por jobs batch, procedures, código desktop e planilhas. A CodeHero trata esse caso lendo toda a base, reescrevendo a arquitetura em Go, Rust, TypeScript e Postgres quando adequado e verificando paridade contra tráfego de produção registrado, com entrega em menos de 30 dias. Isso pode mudar a opção de correção, mas o comprador ainda precisa de propriedade limpa, evidência confiável e autoridade para operar.

Não termine o relatório com uma nota média. Nomeie a condição em que a transação ainda funciona. Se o comprador consegue controlar o release, reter ou transferir conhecimento crítico, resolver exceções de licença e medir paridade, o risco de engenharia tem limites. Se essas condições não forem atendidas, o preço deve carregar a incerteza, em vez de deixar a integração descobri-la após as assinaturas.