Source code due diligence assesses whether a target company's codebase is maintainable, secure enough, legally manageable and able to support the investment case. It reviews structure, test coverage, dependency health, security patterns and development history, but it should be scoped to deal risk rather than treated as an exhaustive engineering audit.
For investors and acquirers, the value of source code review is not aesthetic judgement. It is commercial risk translation. A reviewer is asking whether the software can be changed safely, whether core knowledge sits in one person's head, whether the codebase hides remediation cost, and whether the roadmap depends on foundations that are weaker than management suggests.
FoundationState's technical due diligence service usually starts with scoping, data room review, evidence evaluation, leadership interviews, findings calibration and readout. Code review is one possible workstream inside that process. In smaller or faster deals it may be deliberately out of scope. In larger software acquisitions, or where the investment thesis depends on delivery speed, scalability or security, it can be one of the most useful evidence sources.
What does source code due diligence actually assess?
Source code due diligence looks for signals that a codebase can be understood, changed, tested and operated without unreasonable friction. The review may include architecture, modularity, naming and conventions, test coverage, dependency health, security patterns, deployment configuration, data handling and commit history.
The point is not to read every line. A deal team rarely needs a perfect inventory of every defect. It needs to understand whether the codebase supports the value being underwritten. If management claims that new enterprise features can ship quickly, the reviewer tests whether the code is structured for change. If the product processes sensitive data, the reviewer looks for access control, input validation, auditability and secure development patterns.
An investor-grade review should also separate routine engineering imperfections from deal-relevant findings. Every codebase has compromises. The important question is whether those compromises create cost, delay, security exposure, customer churn risk or key-person dependency that should affect valuation, warranties or the post-close plan.
| Review area | Evidence reviewed | Commercial risk it helps test |
|---|---|---|
| Structure and modularity | Repository layout, boundaries, duplication, coupling | Whether change will be slow, risky or dependent on a small group |
| Test coverage | Unit, integration and end-to-end tests, CI behaviour | Whether releases can move quickly without breaking core workflows |
| Security patterns | Authentication, authorisation, input handling, secrets management | Whether the buyer inherits avoidable security exposure |
| Dependency health | Package age, update discipline, abandoned libraries | Whether remediation or upgrade work is already overdue |
| Commit history | Review discipline, contributor concentration, release cadence | Whether the team's delivery claims match how work actually happens |
When is source code review needed in a deal?
Code review is most valuable when software quality is central to the investment thesis. That includes SaaS platforms being bought for growth, products with security-sensitive workflows, businesses with large custom codebases, companies claiming strong proprietary technology, or targets where earlier diligence has surfaced technical debt, delivery risk or unexplained engineering slowdown.
It is not always necessary. A focused Small-tier technical diligence engagement may exclude code review because the deal needs a fast baseline view of workforce tooling, public footprint, cloud configuration, access control and obvious operational risk. For early-stage companies, the more important question may be whether the team has made rational trade-offs, not whether the codebase already looks enterprise-grade.
The scoping decision should be explicit. Investors should ask: would access to source code materially improve confidence in the deal decision? If the answer is no, a lighter review may be better. If the answer is yes, the scope should define which repositories, branches, services and evidence types matter, and what the reviewer is not attempting to prove.
Targets can prepare without over-polishing. Useful preparation includes a repository map, architecture overview, dependency inventory, test and coverage reports, CI/CD pipeline notes, release history, access model and a list of known technical debt. That material helps reviewers focus on deal-relevant areas quickly. It also reduces the risk that normal context gaps are mistaken for hidden problems.
What signals show maintainability and architecture quality?
Maintainable code usually has coherent boundaries. A reviewer should be able to see where domain logic lives, how data flows, how services or modules depend on each other, and how common behaviours are reused. A messy codebase is not automatically a deal problem, but unclear boundaries raise the cost of every future product change.
Architecture quality is also visible in what the code makes easy. Can a developer add a feature without touching unrelated areas? Are integrations isolated, or scattered across the codebase? Are configuration and secrets separated from application logic? Are risky operations wrapped in clear abstractions, or repeated in different forms across the product?
These signals connect directly to the technical due diligence red flags investors miss. Key-person dependency, undocumented tribal knowledge and chronic firefighting often show up in source code before they appear in management reporting. If only one developer understands the payment flow, permissions model or data import pipeline, the buyer is underwriting a people risk as much as a code risk.
Maintainability review should stay grounded. The reviewer is not enforcing a personal preference for a framework, folder layout or testing style. They are asking whether a competent team could keep improving the product at the pace assumed in the investment case.
How do reviewers use tooling without over-trusting it?
Static analysis, dependency scanners, secret scanners and test coverage tools are useful accelerators. They can identify vulnerable packages, obvious security issues, dead code, duplicated patterns, weak typing, missing tests and accidental secrets. They can also create false confidence if their output is treated as the review itself.
The OWASP Code Review Guide is useful here because it frames code review as a combination of process, manual judgement and security pattern recognition, not just tool output. In diligence, that distinction matters. Automated tools can point reviewers towards areas worth testing, but they cannot fully explain why a design is risky, whether a compromise was justified, or how difficult remediation will be.
Good diligence combines tooling with sampling and interviews. A reviewer may run automated checks, inspect high-risk flows manually, compare the code with architecture diagrams, and ask engineers why particular decisions were made. That triangulation is what turns technical observations into deal findings.
What can commit history and dependencies reveal?
Commit history is not a performance scorecard, but it can reveal how the organisation works. A healthy history often shows small changes, review discipline, multiple contributors and regular delivery. A riskier history may show large unreviewed changes, long quiet periods before rushed releases, abandoned branches, or one person touching the majority of critical code.
Contributor concentration matters because it may indicate key-person dependency. If one founder or contractor owns the complex parts of the product, the buyer needs to understand retention, documentation and handover risk. That finding may be more commercially important than a long list of minor code smells.
Dependencies tell a similar story. A modern software business will use open source and third-party packages; that is normal. The diligence question is whether dependency choices are understood, maintained and updated. Stale packages, abandoned libraries, unsupported runtime versions and unmanaged upgrade paths can create security risk, roadmap drag and hidden remediation cost.
This connects to technical debt valuation. Debt is not only visible in old code. It appears when the team cannot safely upgrade, test or change the product without a disproportionate amount of work. Source code review helps estimate whether that drag is manageable or structural.
How is code confidentiality protected?
Targets are often rightly cautious about sharing source code. A codebase may contain proprietary logic, customer-specific configuration, credentials that should not be present, or evidence of sensitive business processes. A good diligence process protects confidentiality while still giving the buyer enough evidence to assess risk.
Common approaches include restricted repository access, read-only accounts, time-limited access, clean-room review, screen-shared walkthroughs, supervised sessions, or reviewer-only access with summarised findings for the deal team. The right model depends on transaction stage, sensitivity, target maturity and legal agreements already in place.
The review should also minimise unnecessary copying. Reviewers should avoid exporting repositories, pasting proprietary code into external tools, or including detailed code snippets in reports unless there is a clear reason and permission. Findings should describe the risk, evidence type and remediation implication without exposing more intellectual property than the deal team needs.
Confidentiality cuts both ways. Buyers need enough assurance to avoid blind underwriting. Targets need confidence that diligence will not leak their product. Clear scoping, access controls and report discipline make both possible.
What can source code review not tell investors?
Code review cannot prove product-market fit, customer demand, roadmap priority, pricing power or management quality on its own. It can show whether the product is easier or harder to change, but it cannot decide whether the market wants the next feature. That is why technical due diligence should be paired with product, commercial and customer evidence where the thesis depends on growth.
It also cannot provide absolute security assurance. A clean review does not mean a product is breach-proof. It means the sampled evidence did not reveal material issues within the agreed scope. Security findings still need to be assessed alongside infrastructure, identity, operational process, incident history and data protection evidence.
The strongest output is a calibrated view: which codebase risks are material, which are normal engineering debt, which require pre-close clarification, and which should become post-close remediation work. That is more useful to investors than a generic pass or fail.
Get an independent view before code quality assumptions become valuation assumptions. Contact FoundationState to scope technical due diligence around source code quality, maintainability, security patterns and the delivery risks behind your next investment.
Frequently Asked Questions
Is source code review always part of technical due diligence?
No. Source code review should be scoped to deal risk. It is most useful when proprietary software quality, delivery speed, security posture or technical debt materially affect the investment case. In smaller or faster engagements, a buyer may prioritise architecture, infrastructure, access control, security hygiene and team interviews instead of direct repository review.
How is code confidentiality protected during review?
Confidentiality is usually protected through read-only access, time-limited permissions, clean-room review, supervised walkthroughs or reviewer-only access. Reports should describe risks and remediation implications without exposing unnecessary proprietary code. The process should be agreed before access is granted, with legal protections and practical controls aligned to transaction sensitivity.
What does bad code look like to a reviewer?
Bad code in diligence is code that creates commercial risk: unclear boundaries, fragile change paths, limited tests, security shortcuts, stale dependencies, duplicated logic, undocumented critical flows or reliance on one developer's knowledge. It is not simply code that uses an unfashionable framework or a style the reviewer personally dislikes.
