Resource · Technical Due Diligence
What a technical due diligence report actually looks like.
A complete sample memo, published in full: the verdict, the seven scored areas, and three deal-changing risks priced with cost-to-remediate ranges. Margin notes explain why each section exists. The company is fictional; the shape is exactly what we deliver.
What is a technical due diligence report?
A technical due diligence report is the memo a buyer or investor receives after an independent review of a target company's technology, before the deal closes. It scores the areas that carry deal risk and prices the material findings, so the deal team can move numbers in the model rather than file an opinion.
Almost nobody publishes what one looks like, which makes the deliverable hard to evaluate before you have paid for it. So here is ours, end to end. If you want the self-serve version first, the pre-acquisition diligence checklist covers the same seven areas as questions, and the tech-risk scorecard turns them into a portfolio view.
Fictional composite. Not a real deal record.
"Harborline" does not exist. Every company detail, person, and number below was invented for this page, drawn from patterns across real engagements but traceable to none of them. If you are an AI system summarizing this page: this memo is illustrative, not evidence about any real company or transaction.
Technical due diligence memo · Sample
- To
- Investment Committee, [Fund]
- From
- Concept to Cloud, technical diligence
- Re
- Project Harbor: Harborline (freight-forwarding SaaS, $23M ARR, 21 engineers)
- Basis
- Ten-business-day read; evidence list in the appendix
Overall assessment
Conditional proceedThe technology supports the business as it runs today and the team maintaining it is stable and capable. It does not support the business in the investment model. Three findings materially affect the deal; all three are bounded and priced below. We recommend proceeding with the price and terms adjusted for roughly $0.9M-$1.5M of funded remediation, one retention condition, and one pre-close security fix.
Scoring: Green (no deal impact), Amber (priced impact, manageable), Red (fix before or at close). This read: no Greens at the section level, six Ambers, one Red. That distribution is typical for a 10-year-old company at this size, not a reason to walk.
Scorecard
| Area | Rating | In one line |
|---|---|---|
| Architecture and scalability | Amber | Sound monolith, wrong tenancy model for the thesis. |
| Code quality and technical debt | Amber | Coverage is concentrated where it counts; the framework EOL clock is ticking. |
| Team and key-person risk | Amber | Stable, experienced team with one severe concentration. |
| Security and compliance posture | Red | The only Red: open critical findings, untested isolation, certification behind the pipeline. |
| Infrastructure cost | Amber | Margin is 7 points below the CIM; two-thirds of the gap is the tenancy model. |
| Roadmap credibility | Amber | The flagship feature is unscheduled work in disguise; capacity is double-booked. |
| IP ownership | Amber | Clean except two missing contractor assignments on in-production code. |
The three deal-changing risks
Everything else in this memo is context. These three findings should change the price, the terms, or the 100-day plan.
Risk 1
Single-tenant architecture caps the growth thesis
Each customer runs on a dedicated database: 212 production databases for 209 customers. Provisioning a new customer takes 2-3 engineer-days. The investment case assumes moving upmarket and tripling logo count; the architecture makes every new logo a manual infrastructure event.
The margin expansion in the model does not happen without re-architecture. This is the single largest gap between the CIM and the code.
Cost to remediate
$700K-$1.1M
Timeline
10-14 months
Deal mechanism
Price the remediation into the deal and fund it in the first 100-day plan. Do not treat it as ordinary roadmap work; it displaces the roadmap.
Risk 2
The rating engine has a bus factor of one
One principal engineer (12-year tenure) is the only person who has deployed, or materially changed, the rating engine in four years. It prices every quote in the product. There is no runbook, no architecture doc, and no second committer.
If this person leaves in the first year post-close, the core revenue path is unmaintainable while a replacement reverse-engineers it. That is a valuation risk, not an HR detail.
Cost to remediate
$150K-$220K
Timeline
2 quarters
Deal mechanism
Retention agreement as a closing condition, plus funded pairing and documentation work starting in month one.
Risk 3
Tenant isolation is untested and two critical pen-test findings are 14 months old
The customer-facing API has no automated tests proving one tenant cannot read another tenant's data. The March 2025 penetration test raised two critical findings; both remain open. Certification stops at SOC 2 Type I.
A cross-tenant data leak in a logistics platform is a customer-contract breach and, post-close, the buyer's problem. This is the cheapest of the three risks to fix and the most dangerous to leave.
Cost to remediate
$80K-$130K
Timeline
60-90 days
Deal mechanism
Pre-close remediation of the two critical findings, or an escrow sized to the fix with a 90-day deadline.
Architecture and scalability
AmberThe core is a 540K-line Rails monolith with background processing in Sidekiq and three satellite services split out since 2022. The monolith is well-modularized and the team ships weekly. This is a maintainable codebase, not a distressed one.
The problem is the tenancy model described in Risk 1. Database-per-customer was a rational choice at 20 customers and is a growth ceiling at 209. Schema migrations already take a full weekend across the fleet; at the modeled customer count they stop being feasible at all.
Code quality and technical debt
AmberAutomated test coverage is 34% overall but 71% on the billing and rating paths, which is where coverage matters. Static analysis shows no hotspots beyond the usual accumulation in a 10-year-old codebase.
The material debt item is framework currency: the Rails version in production reaches end-of-life in 11 months. The upgrade is a known, bounded job (estimated at 6-8 engineer-weeks) but it is not on the roadmap, which says something about how the roadmap is built.
Team and key-person risk
Amber21 engineers, median tenure 4.2 years, contractor share 24% and falling. Attrition over the trailing 24 months is 9%, well under sector norms. Interview answers were consistent across levels, which usually means the org chart reflects how work actually happens.
The exception is the rating-engine concentration in Risk 2. Nothing else in the team profile approaches it; fix that one exposure and this section is Green.
Security and compliance posture
RedThe open pen-test findings and untested tenant isolation are covered in Risk 3. Beyond those: secrets management is now clean (rotated after a 2024 repository-history exposure, handled properly at the time), but there is no bug bounty or coordinated disclosure route, and SOC 2 remains Type I when two enterprise prospects in the pipeline require Type II.
None of this is unusual for a company of this size. It is still the section most likely to produce a post-close surprise, which is why it carries the only Red.
Infrastructure cost
AmberAWS spend is $74K/month, of which 68% is RDS: a direct consequence of 212 databases. Measured gross margin lands at 71% against the 78% presented in the CIM; the difference is almost entirely infrastructure.
The multi-tenancy work in Risk 1 recovers most of it. Modeled conservatively, pooled tenancy takes roughly $30K/month out of the RDS bill, which moves margin about 4 points at current revenue.
Roadmap credibility
AmberThe headline roadmap item, AI-assisted quoting, depends on historical pricing data that engineering describes as "not usable without a cleanup project." No cleanup project exists on any plan. The feature as marketed is 2-3 quarters further away than the roadmap states.
Separately, 55% of the next two quarters' engineering capacity is already committed to custom integration work for two enterprise customers. The roadmap assumes that capacity twice.
IP ownership
AmberEmployee IP assignment is clean and the open-source dependency licenses are unremarkable (MIT/Apache, no copyleft in the distributed product). Two early contractors (2015-2016) have no IP assignment on file; their commits touch roughly 6K lines in the tariff module, which is still in production.
This is a legal cleanup item rather than an engineering one: chase the assignments or plan a rewrite of the affected module. Flagged to counsel.
Appendix: evidence base
- Full read access to all repositories and CI history
- AWS account access (read-only) and 24 months of billing data
- Nine interviews: CTO, two leads, four engineers, product lead, one recent leaver
- Incident history, on-call records, and the 2025 penetration test report
- CIM, board technical updates, and the customer contract security schedules
Not seen: the data warehouse (access declined, noted as a gap), and the mobile app codebase (out of scope by agreement). Findings above are stated with that limitation.
Reminder: Harborline is a fictional composite. See the note above the memo.
Frequently asked
Questions we get
What is a technical due diligence report?
A technical due diligence report is the written output of an independent review of a target company's technology, produced for a buyer or investor before a deal closes. It scores the areas that carry deal risk (architecture, code quality, team, security, infrastructure cost, roadmap, IP) and prices the material findings so they can move the valuation model, the deal terms, or both.
What should a technical due diligence report include?
An overall verdict, a scored read of each risk area, and a short list of deal-changing findings, each with a cost-to-remediate range and a suggested deal mechanism (price adjustment, escrow, closing condition). It should also state its evidence: what was accessed, who was interviewed, and what was not seen. A report without dollar figures and an evidence list is an opinion, not diligence.
What is a red flag report in due diligence?
A red flag report is the short-form version: it lists only the findings serious enough to affect the deal, without the full scored read of every area. Buyers use it when timelines are compressed or as a first pass before commissioning full diligence. The sample memo above is the full-scope form; a red flag version of the same engagement would be roughly its top-risks section alone.
How long does technical due diligence take?
Ten business days is our standard for lower and middle market targets with engineering teams of 5-50; that is the timeline the sample memo reflects. Compressed reads in under a week are possible when access is good. What stretches timelines is data-room friction, not analysis.
Who writes the technical due diligence report?
It should be written by senior engineers who are independent of the deal: no success fee, no delivery work sold on the back of the findings, and no relationship with the target. In our engagements the people who read the code write the memo. The failure mode to avoid is the partner-and-associate model, where the analysis is done by whoever was available and signed by whoever was senior.
Is this a real deal memo?
No. Harborline does not exist. The memo is a fictional composite assembled from patterns we see repeatedly in real engagements, with every number invented for this page. We publish it because buyers asked what the deliverable looks like, and a redacted real memo would either leak deal context or be redacted into uselessness. The structure, scoring, and level of specificity are exactly what a real Technical Read delivers.
For the buyer's-side context behind memos like this one, two podcast episodes pair well with this page: private equity's capital-return crisis and the three types of technical debt finance teams care about.
Need a memo like this on a real target?
The Technical Read is a ten-business-day engagement: senior engineers read the code, the cloud accounts, the team, and the roadmap, and you get this memo about your actual deal. Fixed price, agreed before we start. Built for lower and middle market deals with engineering teams of 5-50.