Most TDD reports are too long, too generic, and tell you very little about whether the software is a real risk to the transaction. Here is what a good technical assessment should actually contain — and what to do if yours is missing it.
Most technical due diligence reports are too long, too generic, and tell you very little about whether the software is actually a risk to the transaction. A report that catalogues every code smell across 80 pages is not due diligence — it is a codebase printout. Here is what a good technical assessment should actually contain, and what to do if yours is missing it.
What technical due diligence is actually for
TDD is not there to confirm that the software works. If it didn't work at a basic level, the deal would not have reached this stage. The purpose of technical due diligence is to surface the risk that is not yet visible — the decisions, structures, and dependencies that will become expensive problems post-acquisition or post-investment.
A useful TDD report answers one question above all others: what will it cost to maintain, operate, and scale this system over the next three years, and what is the risk that cost is significantly higher than expected?
Everything in the report should connect back to that question.
Five things a good report must cover
How the system is structured determines how expensive it is to change and how far it can scale before requiring significant rework. A monolith is not inherently bad — but a poorly structured monolith that cannot be extended without rewriting large sections is a material risk.
Not a penetration test, but a structured review of authentication, access control, data handling, and dependency management. Outdated dependencies with known vulnerabilities, hardcoded credentials, and missing input validation are common findings that carry genuine liability.
The bus factor: how many people need to leave before the system becomes unmaintainable? A system built and understood by one developer who is leaving post-acquisition is a significantly different risk profile than one with distributed knowledge and clear documentation.
Not a list of things that are wrong — a quantified estimate of what it will cost to address the material issues. Debt that represents 3 months of developer time is a very different conversation from debt that represents 18 months.
Is the system's cost structure sustainable at current scale? Does it scale linearly with revenue, or does the cost curve become punishing before the business reaches the revenue targets in the forecast model? Cloud cost architecture deserves as much scrutiny as the code.
Red flags that actually matter versus noise
A common failure mode in TDD reports is the conflation of concerning findings with trivial ones. Code style inconsistencies are not a risk. Missing semicolons are not a risk. A 12-year-old framework with a single maintainer on whom the entire authentication system depends is a risk.
A good report distinguishes clearly between findings that represent material business risk and findings that are cosmetic or easily addressable. The executive summary — which is often the only section a non-technical investor reads — must reflect that distinction accurately.
"A 60-page report that lists every code smell is not useful. A 12-page report that identifies three structural risks with honest cost projections is."
What makes an assessment investment-grade
The assessor matters as much as the methodology. A report written by a developer who has not operated systems at scale will look at the code but miss the operational risk. A report written by someone without commercial context will find technical issues but not connect them to the business implications that actually inform deal decisions.
An investment-grade technical assessment is conducted by someone who has built and operated real systems under commercial pressure — and who understands what findings mean for the deal structure, price adjustment, or warranty clauses that may follow.
The output should be immediately actionable: a clear risk register with materiality ratings, a cost-to-remediate estimate, and a recommendation on whether the findings support, modify, or raise concerns about the transaction on its current terms. Our technical due diligence service produces exactly this kind of output.
When to commission it and what to share
TDD should happen before exclusivity where possible — findings can affect both price and terms. At minimum, it should be completed before final close and with sufficient time to act on material findings.
Share the scope of what will be reviewed with the target early. Access to production systems, infrastructure accounts, codebase, and the development team (for brief technical interviews) produces materially better findings than a static code review in isolation. A seller who resists access to the system they are selling is itself a finding worth noting.
A deal that closes without a proper technical assessment has simply deferred the discovery of risk, not avoided it. For context on what to budget and expect, see our fixed-fee pricing for technical assessments.
Written by gigtech
gigtech is a software consulting and product development firm with 20+ years of hands-on engineering experience. We help businesses make better technical decisions, reduce costs, and build systems that last.
About gigtech ›