New! Listen to Concept to Cloud - Real stories from the trenches of software engineering

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 proceed

The 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

AreaRatingIn one line
Architecture and scalabilityAmberSound monolith, wrong tenancy model for the thesis.
Code quality and technical debtAmberCoverage is concentrated where it counts; the framework EOL clock is ticking.
Team and key-person riskAmberStable, experienced team with one severe concentration.
Security and compliance postureRedThe only Red: open critical findings, untested isolation, certification behind the pipeline.
Infrastructure costAmberMargin is 7 points below the CIM; two-thirds of the gap is the tenancy model.
Roadmap credibilityAmberThe flagship feature is unscheduled work in disguise; capacity is double-booked.
IP ownershipAmberClean 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

Amber

The 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

Amber

Automated 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

Amber

21 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

Red

The 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

Amber

AWS 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

Amber

The 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

Amber

Employee 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.