Direct answer: A technical due diligence review checks five things before you acquire, inherit, or take over a codebase: code quality and structure, test coverage, security posture, who actually controls the infrastructure, and the health of third-party dependencies. Skip this and you are buying a black box — the price you agree to has nothing underneath it verifying what you are actually getting.
When this review is actually necessary
The most common real-world trigger is not an acquisition — it is auditing the code before releasing a final milestone payment to an outsourced development vendor, which is a reasonable, normal request on any project, not an accusation. The same review also applies to switching from one development vendor to another and inheriting an existing codebase, bringing a previously outsourced project in-house to manage directly, and formal acquisition or investment due diligence. All four share the same problem — you are taking financial or operational responsibility for code you did not write and cannot fully assess by reading a demo.
Code quality and test coverage
A reviewer reads the actual source for structure and maintainability — consistent patterns versus a tangle of one-off workarounds, meaningful commit history versus one giant unexplained initial commit, and whether automated tests exist to catch regressions before they reach users. Low or absent test coverage does not automatically disqualify a codebase, but it does change the real cost of every future change — that cost belongs in your valuation or budget, not as a surprise afterward.
Security posture
Authentication and authorization implementation, how sensitive data is stored and transmitted, whether dependencies carry known vulnerabilities, and whether basic protections (input validation, rate limiting, HTTPS enforcement) are actually in place rather than assumed. This overlaps with a full penetration test but is narrower — due diligence flags structural security risk; a dedicated audit goes deeper if red flags surface here.
Infrastructure and credential ownership
The single most consequential check, and the one non-technical buyers can partly do themselves: confirm who actually controls the domain registrar, hosting/cloud accounts, database, CI/CD pipeline, and any paid third-party services the product depends on. Code quality problems are fixable with time and budget. A codebase where the buyer does not independently control production infrastructure is an operational dependency on the seller or prior vendor that can stop the business cold if that relationship ends badly. See our NDA and IP ownership guide for the contractual side of this same problem going forward.
Dependency and technical debt assessment
Outdated frameworks approaching end-of-life, abandoned open-source packages no longer receiving security patches, and architectural decisions that will make specific future features disproportionately expensive to build. None of this needs to be a dealbreaker — it needs to be quantified, so it can be factored into price, timeline, or budget rather than discovered after the deal closes.
What a real report looks like
A written summary organized by category, a severity rating per finding, an estimated remediation effort for anything critical, and — importantly — an explicit statement of what was and was not verified within the review's time and access constraints. A report that reads as uniformly positive with no caveats is usually a shallow one; a credible review names its own limits.
If the review surfaces that the codebase needs modernization rather than a rebuild, our legacy software modernization guide covers what that process looks like in practice.
Frequently Asked Questions
Three common triggers: acquiring or investing in a company with a software product, switching development vendors and inheriting an existing codebase, or bringing a previously outsourced project in-house. In each case, you are taking on a codebase you did not build, and need an honest, independent read on its actual condition before committing.
Five core areas: code quality and structure (is it maintainable or a tangle of workarounds), test coverage (can changes be made safely), security posture (authentication, data handling, known vulnerabilities), infrastructure and credential ownership (who actually controls the servers, domains, and accounts), and dependency health (outdated or abandoned libraries carrying risk). A thorough review produces a written report, not just a verbal impression.
Partially — a non-technical buyer can at minimum verify who holds the domain registrar, hosting/cloud accounts, source code repository, and any third-party API keys, since ownership gaps here are visible without reading code. Actual code quality, security, and architecture assessment genuinely requires a qualified engineer reviewing the codebase directly — this is not a corner worth cutting for anything beyond a trivial project.
Missing or unclear ownership of critical infrastructure — a codebase where the buyer does not actually control the production servers, domain, database, or deployment pipeline independently of the original developer or vendor. Code quality issues are fixable with time and budget; a locked-out infrastructure dependency is an operational risk that can stop the business cold.
Yes — this is the most common real-world trigger for this kind of review, more so than an acquisition. Before releasing a final milestone payment on an outsourced build, verify independently that you actually control the source repository, hosting, and any third-party accounts, and have a qualified engineer (internal or independent) confirm the delivered code matches what was scoped and functions as claimed. This is a normal, reasonable request to make of any legitimate vendor, not an accusation — a vendor who resists a pre-final-payment review is a signal worth taking seriously.
For a small-to-mid-sized codebase, a focused review typically runs from a few days to two weeks depending on codebase size and how much documentation exists. Rushing this to fit a closing deadline is a common mistake — a shallow review that misses infrastructure ownership or security gaps defeats the purpose of doing one at all.
A written summary of findings by category (code quality, security, infrastructure, dependencies), a severity rating for each issue found, an estimate of the effort needed to remediate critical items, and a clear statement of what could not be verified within the review scope — an honest report says what it did not check, not just what it did.