Technical due diligence changes the price

Technical due diligence is not a code-quality contest. A buyer wants to know which technical facts change future cash flow, threaten ownership of the asset, delay integration, or make the business dependent on one person who could leave after closing. Clean abstractions are pleasant. Predictable delivery, provable rights, and controlled operational risk affect the deal.

I have seen buyers spend days arguing about naming conventions while a nightly settlement job had no owner, no repeatable build, and no test that could prove yesterday's output matched today's. That is backwards. The useful review follows business consequences through the code, deployment path, people, and contracts, then states what each finding should do to price or terms.

The buyer is pricing uncertainty, not judging style

A buyer uses technical due diligence to turn unknowns into a costed plan. The codebase is evidence, but it is only one piece. Repository history, build systems, production telemetry, incident records, dependency manifests, architecture diagrams, access controls, and interviews reveal whether the software can keep earning money under new ownership.

The first distinction people blur is defect versus deal risk. A slow query with a clear fix, an owner, and a bounded blast radius is a defect. An undocumented billing engine that only one contractor understands is deal risk, even if it has run without an incident for years. The first creates an engineering ticket. The second can justify a holdback, a closing condition, a transition agreement, or a lower valuation because its failure probability and recovery cost are both hard to bound.

Reviewers should connect every material finding to an economic mechanism. Does it require immediate remediation? Does it block a planned product combination? Could it interrupt revenue, breach a customer contract, or prevent the buyer from operating the asset? Does the buyer need to retain a specific employee or buy a commercial licence? A finding without that bridge is an observation, not diligence.

Severity labels alone obscure this logic. Two findings marked "high" can have different deal effects. A public administrative endpoint may require action before closing. A database at capacity may justify a funded post-close project. A disputed code contribution may require an indemnity. State the consequence and the available control before choosing a colour.

The buyer also needs a confidence level. If reviewers cannot run the system, access production-like data, or interview the operator, they should not silently mark the area clean. They should record the evidence gap as its own risk. Missing evidence often changes terms more than a known defect because nobody can price the upper bound honestly.

Repository access must prove what is being bought

Repository access should establish completeness, history, and provenance before anyone reviews architecture. A polished application repository can distract from missing deployment scripts, report generators, firmware, database jobs, or a separate directory copied manually onto production servers. The transaction covers an operating system in the broad sense, not whichever repository the seller opened first.

Ask for an inventory that maps every production component to a repository, build path, deployment owner, runtime, data store, and environment. Reconcile that inventory against cloud accounts, schedulers, package registries, server file systems, mobile stores, DNS records, and vendor invoices. If an executable earns revenue but has no source location, the buyer may be acquiring a binary it cannot reproduce.

History matters because a current snapshot cannot show authorship or development concentration. Obtain full commit history, tags, branches needed for supported releases, submodules, large-file storage, and build artefacts that are not reproducible. Check whether a last-minute import flattened years of history. That may be innocent, but it prevents reliable contributor analysis and makes intellectual-property representations harder to test.

A short triage sequence gives a reviewer a useful first map. Run it in an isolated copy, review each command before execution, and adapt paths for the repository:

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

The expected output is not a pass or fail. It is a set of leads: whether history is shallow, which identities dominate commits, where source clusters sit, which dependency ecosystems exist, and where licence notices live. Alias cleanup and bot exclusion come next. Never equate commit count with ownership or skill; generated changes, imports, pair programming, and rebases distort it.

Finally, reproduce one supported release from a documented commit. Record the toolchain, secrets needed, external artefacts, build duration, and resulting checksums where deterministic output is expected. A build that succeeds only on an employee's laptop is not reproducible merely because that laptop is available during diligence.

Key-person risk appears in decisions and operations

Key-person risk exists when one person's absence can stop a material change, recovery, or business process. Commit concentration is a clue, not the diagnosis. The risk hides in undocumented decisions, private credentials, manual production rituals, vendor relationships, data corrections, and the authority to approve a release.

Start with business-critical paths: order capture, settlement, invoicing, month-end close, regulatory reporting, fulfilment, and customer access. For each path, ask who can explain it, change it, deploy it, and recover it. Four names are better than one only if those people can act independently. A team that always calls the former founder before touching a pricing rule still has one effective owner.

Test knowledge with work, not interviews alone. Ask a second engineer to trace a production transaction, locate the governing rule, make a harmless change in a non-production environment, run the relevant tests, and describe rollback. Ask the on-call backup to restore a representative backup and diagnose a failed scheduled job. The observer should note where the person needs undocumented information or another employee's permission.

The awkward case is a capable founder who plans to leave. Buyers sometimes accept a vague promise to remain available because replacing deep context sounds impolite or expensive. That promise is weak. Define a transition deliverable: named runbooks, recorded walkthroughs, credential transfer, paired releases, an incident exercise, and acceptance by the people who will operate the system. Tie completion to a closing condition, consulting agreement, or retention package when the dependency is material.

Do not confuse old technology with single-expert risk. A well-run COBOL estate with several operators, recorded production behaviour, automated builds, and rehearsed recovery may be safer than a fashionable service written last year by one departed contractor. Technology age affects hiring and change cost. Concentrated knowledge affects continuity. They meet in some systems, but the evidence and remedy differ.

Price moves when the buyer must fund duplicate staffing, retain someone on exceptional terms, postpone integration, or accept outage exposure that cannot be insured away. If a practical knowledge-transfer plan can close the gap before closing, make it a condition. If the seller cannot transfer the knowledge because nobody still has it, treat remediation as part of the investment case rather than a documentation chore.

Licence exposure starts with provenance

Licence review must answer whether the seller has the right to transfer and operate every material part of the product. A dependency scanner helps, but it cannot prove employee assignment, contractor ownership, copied snippets, purchased components, training data rights, or terms attached to code received from a partner. Those are provenance questions.

Build a software bill of materials from manifests, lockfiles, vendored directories, container images, generated clients, mobile packages, and operating-system packages shipped with the product. Then reconcile it with what actually reaches customers or production. GitHub's dependency graph documentation says its static analysis parses supported manifest and lock files. That boundary matters: an old JavaScript file pasted into a vendor directory or a binary checked into a release folder can sit outside the manifest graph.

Use SPDX identifiers to normalize findings. The SPDX specification permits expressions with AND, OR, and WITH, which preserve distinctions that a spreadsheet column called "licence" destroys. GPL-2.0-only OR MIT offers a choice; LGPL-2.1-only AND BSD-2-Clause says both apply to the described package set. A reviewer who collapses both to a list of names can recommend the wrong remediation.

Scanning produces allegations that need disposition. For each material result, capture the component and version, how it enters the product, whether it is modified, where it is distributed or hosted, the detected and concluded licence, required notices or source offers, owner, and evidence. Counsel should decide legal interpretation. Engineering should prove usage and replaceability. Neither discipline can finish the review alone.

First-party ownership deserves the same care. Match contributors to employment dates, invention-assignment agreements, contractor statements of work, acquisition schedules, and any code imported from earlier ventures. Look closely at commits from personal email addresses, external domains, interns, agencies, and founders before incorporation. A signed warranty in the purchase agreement is useful, but it does not make a third party's ownership claim disappear.

The price changes when a component cannot lawfully ship under the intended model, replacement would delay the buyer's plan, or ownership remains contestable. Lesser gaps often fit a closing schedule, notice cleanup, targeted indemnity, or escrow. Do not call every copyleft dependency fatal. Distribution, linking, modification, and actual licence text determine obligations, so general labels are a poor substitute for counsel's analysis.

A test suite is evidence only when it can fail

The state of the test suite matters because the buyer will change the system after closing. File counts and coverage percentages say little about whether tests detect business regressions. A thousand assertions around data access cannot protect a settlement calculation that nobody has encoded as an expected outcome.

Run the suite from a clean environment using the documented command. Note setup time, external services, secret handling, duration, flaky retries, skipped tests, and failures on the default branch. Then introduce a small controlled fault in an important rule and confirm that a relevant test fails for the expected reason. Revert the change immediately. This mutation is often more informative than a coverage report because it tests the test's ability to object.

Separate four forms of evidence. Unit tests protect local rules. Integration tests prove components agree on protocols and persistence. End-to-end tests exercise deployed paths but often cover few permutations. Production comparison or replay tests show whether a replacement preserves observed behaviour. One cannot stand in for all the others. A green browser suite does not validate a year-end calculation, and high unit coverage does not prove database migrations work.

Read failure history in continuous integration. A red default branch that everyone ignores shows a control failure, even if each failure has an explanation. So does a suite that passes only after reruns. Ask how teams quarantine flaky tests, who may override checks, whether protected branches require results, and how release hotfixes differ from the normal path.

Test data creates its own risk. Determine whether fixtures contain customer or employee data, how they are masked, who can access them, and whether deletion obligations reach backups and developer copies. A buyer does not want to discover during integration that the fastest test environment depends on an unmanaged production dump.

Translate the result into change cost. Weak tests mean the buyer must choose among slower releases, more manual checking, a higher incident rate, or an early investment in characterization tests. If the roadmap assumes rapid integration or a platform rewrite, missing behavioural evidence can move price because the buyer has no cheap way to prove that changed software still produces the same outcomes.

Operability reveals the hidden engineering bill

Operability shows how much labour the software consumes after deployment. Buyers should inspect releases, observability, backup recovery, incident handling, capacity, and routine data repair. A product can look stable because two experienced people quietly prevent visible failures every day. Their labour belongs in the cost model.

Observe a normal release and an emergency rollback if timing permits. Identify manual gates, shared accounts, undocumented commands, mutable servers, and approvals that exist only in chat. Confirm that the deployed version can be traced to source and that the team can say which database migrations ran. A release document that describes the ideal path but not the one people use is decoration.

Ask for incident records and sample alerts, then trace a recent issue from detection through diagnosis and correction. Useful evidence includes timestamps, alert ownership, logs, metrics, customer communication, follow-up work, and proof that the correction reached production. Absence of recorded incidents can mean excellent reliability. It can also mean the company does not record incidents. Telemetry and interviews distinguish those cases.

Backups deserve a restore test. A screenshot showing scheduled backups proves that a job ran, not that the business can recover. Restore representative data into an isolated environment, check integrity, measure the recovery process, and identify credentials or vendor access needed during a real outage. Compare the result with customer promises and internal recovery objectives without inventing precision the company never measured.

Manual data fixes are another common blind spot. Search ticket systems, scripts, notebooks, and shell history for adjustments to balances, orders, permissions, or reports. Determine who approves them, whether changes are logged, and whether the underlying defect remains. Frequent safe corrections may simply be operations. Unreviewed writes against production create financial and audit exposure.

This work changes price when recurring labour was absent from the seller's margin story, capacity work must precede growth, recovery cannot meet contractual commitments, or integration removes a dependency the system assumes. It changes terms when the seller can complete a restore exercise, transfer accounts, or remediate a dangerous release control before closing.

Architecture matters where it constrains the deal thesis

Architecture review should test the buyer's intended use of the asset, not reward fashionable diagrams. A monolith can be a sensible acquisition if it deploys predictably and supports the growth plan. A set of services can be a liability if ownership is unclear, calls form cycles, and every release requires coordinated changes.

Map business capabilities to modules, data stores, queues, external interfaces, and deployment units. Then put the proposed deal thesis against that map. If the buyer plans to combine customer identity, can the system separate tenants and reconcile identities? If the buyer expects international expansion, where do currency, tax, time zone, and data-location assumptions live? If cost savings depend on consolidating infrastructure, which proprietary services or network boundaries resist the move?

Look for constraints with evidence: unsupported runtimes, vendor end-of-life notices, unbounded tables, synchronous calls in revenue paths, shared database ownership, hard-coded environment assumptions, and batch windows already close to their limit. Avoid converting age into severity automatically. An old runtime behind a stable interface may have a bounded replacement path. A new framework with abandoned dependencies can be harder to operate.

Data is usually the hard part of integration. Inspect schema ownership, migration history, retention rules, identifiers, duplicate handling, audit records, and reconciliation jobs. Ask how the team repairs partial failures and how downstream consumers learn about corrections. If two products use the same word for different entities, an API gateway will not resolve the semantic conflict.

Estimate change by slices of observable behaviour, not lines of code. Identify a representative business path, list its inputs and outputs, record dependencies, and ask the team to explain how they would move or replace it. The answer reveals whether boundaries exist in practice. It also exposes hidden work in stored procedures, desktop clients, spreadsheets, and scheduled jobs that architecture diagrams routinely omit.

A rewrite estimate is not automatically a deduction from price. It becomes one when the buyer's return depends on the rewrite, the existing system blocks another required change, or keeping it imposes a cost the valuation ignored. Otherwise, an unfashionable but controlled system may deserve a planned modernization budget rather than a panic discount.

Security findings need an exploit path and a remedy

Security findings affect a transaction when they create a plausible path to material harm or reveal a missing control the buyer must supply. A scanner's severity score is a starting point. Exposure, privileges, reachable data, existing mitigations, exploit prerequisites, and detection determine the business risk.

Trace identity from customer login through administrative access and machine credentials. Review account lifecycle, privileged roles, multifactor enforcement where supported, service-account ownership, secret storage, and emergency access. Sample actual accounts rather than accepting a policy document. Former staff with live credentials and shared administrator passwords are facts; a generic statement about weak access management is not.

For vulnerabilities, prove whether the affected component is deployed and reachable. Record the version, call path, input control, privilege boundary, data at risk, compensating control, and upgrade or removal path. Dependency findings in test tools deserve different treatment from the same library exposed on an internet-facing service. Both need disposition, but only evidence establishes priority.

Review how the company receives, triages, fixes, and discloses reports. Inspect recent patches and the path from report to release. If there has been a security event, reconcile technical records with customer notices, insurance statements, regulatory correspondence, and deal disclosures. Inconsistency can matter more than the initial flaw because it calls management representations into question.

Regulated customers add requirements, but support for a regulated environment is not a certification. Ask for the exact contract control, system boundary, evidence, and responsible party. Do not let a hosting choice or a penetration-test report turn into a broad compliance claim. Buyers inherit the promises in signed contracts, not the adjectives in a sales deck.

Immediate compromise, undisclosed events, or systemic access failures can become closing blockers. Patchable vulnerabilities usually belong in a remediation schedule with ownership and proof. The distinction keeps the report credible: if every stale package threatens the deal, decision-makers stop listening when one finding truly should.

Findings move price through a small set of mechanisms

A technical issue changes economics through remediation cost, delayed benefit, recurring cost, lost or interrupted revenue, contingent liability, or a higher probability of the deal thesis failing. Reviewers should avoid false precision, but they should still show the mechanism and the assumptions.

Use a decision record for every material finding. This is the minimum shape I expect:

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

This record separates a fact from its response. It also prevents double counting. If the valuation model already includes a modernization programme, reviewers should not deduct the same work again unless diligence expands its scope or risk. If a retention package controls single-expert risk, do not also price the full outage scenario as certain. Show the residual risk after the control.

Different mechanisms call for different deal tools. A known, bounded remediation can reduce price or increase the buyer's budget. A fact the seller can cure may become a closing condition. A specific ownership or disclosure risk may require a representation, indemnity, escrow, or holdback shaped by counsel. Uncertain future investment can affect earn-out metrics or the investment case, though poorly designed earn-outs create their own incentives.

Rank findings by decision, not by scanner severity. The board needs to know what prevents signing, what must happen before closing, what changes value, what belongs in the first operating plan, and what the buyer accepts. Engineering detail should remain available underneath, but a hundred-page issue catalogue cannot substitute for those choices.

Evidence quality deserves its own conclusion

A diligence report should say what reviewers observed, what they received, what they could reproduce, and what remained unavailable. Evidence quality controls confidence in every technical conclusion. A seller-provided diagram and an observed deployment do not deserve equal weight.

Use simple evidence labels: reproduced, observed, documented, reported, and unavailable. Reproduced means the reviewer ran the procedure and obtained the result. Observed means the team performed it while the reviewer watched. Documented means an artefact supports the claim. Reported means someone stated it. These labels do not accuse the seller of dishonesty; they show how much uncertainty remains.

Sampling also needs boundaries. If reviewers inspect three services out of forty, say why those three were selected and which risks the sample cannot address. Choose revenue paths, privileged components, recent changes, and known trouble spots before choosing tidy repositories. Random sampling can supplement judgment, but pure randomness often misses the systems that can damage the deal.

Access constraints are findings when they prevent a material conclusion. A production database may rightly remain off limits, but the seller can often provide schema exports, masked samples, query plans, recorded traffic, or an observed session. When no substitute appears, record the unresolved question and its possible deal effect. Do not turn "not tested" into "no issue found."

The final readout should be comprehensible to engineering, finance, counsel, and the deal lead. Each audience needs the same facts at a different resolution. Keep one source record for evidence and decisions so a late change to a finding does not leave contradictory slides, spreadsheets, and legal schedules.

The first operating plan begins before signing

Good technical due diligence leaves the buyer with an executable ownership plan, even if the deal does not close. The highest-value output is a short list of controlled decisions: which risk changes terms, which evidence is still needed, who owns each pre-close action, and which work enters the funded plan after closing.

Sequence work around dependency and consequence. Secure administrative access before changing deployment. Capture production behaviour before replacing rules. Transfer vendor and operator knowledge before notice periods expire. Rehearse restore before consolidating infrastructure. These are specific controls, not a generic backlog.

Legacy code often concentrates several risks at once: scarce knowledge, weak tests, mixed provenance, and behaviour embedded across batch jobs, stored procedures, desktop code, and spreadsheets. CodeHero addresses that particular modernization case by reading the whole codebase, rewriting the architecture into Go, Rust, TypeScript, and Postgres where appropriate, and checking parity against recorded production traffic, with delivery in under 30 days. That can change the remediation option, but the buyer still needs clean ownership, reliable evidence, and authority to operate the system.

Do not let the report end with an average risk score. Name the condition under which the deal still works. If the buyer can own the release path, retain or transfer critical knowledge, resolve licence exceptions, and measure behavioural parity, the engineering risk has boundaries. Where those conditions cannot be met, the price should carry the uncertainty rather than asking the integration team to discover it after the signatures are dry.