Technical due diligence.

Partners ask sharper questions than founders. The IC meeting reduces twenty pages of report to four numbers and a yes-or-no.

Will this stack scale from 5,000 to 50,000 users without a rewrite? The scalability cliff. A twelve-month dev freeze inside a twenty-four month plan kills the thesis. The DD names the specific breaking points and the engineering quarters needed to move past them.

Who built this, and will they stay for two years? Founder dependency, key-person concentration, retention risk. The cost of replacing the lead architect, in months and dilution. This often becomes a key-man clause or a retention bonus before close.

Are we buying an IP lawsuit? Restrictive open-source license violations. Unowned contractor code. AI training-data provenance that doesn’t hold up under GDPR scrutiny. The kind of finding that surfaces six months after close and consumes a quarter of legal’s time.

Underneath all of these, one running answer: total cost of remediation, in engineer-months, plugged directly into the financial model. Risk that kills a deal versus risk that adjusts terms is a clean pattern. Deal killers tend to be material misrepresentation (claimed certifications that don’t exist, “automation” that isn’t), undisclosed active breaches, or structural rot deep enough that remediation exceeds the runway provided by the round. Term adjusters are bounded technical debt, missing test coverage, weak documentation, dependency hygiene. Adjusters become price chips, earnouts, or escrow holdbacks.

Three windows in the deal cycle.

Pre-term-sheet. The dipstick. 24 to 48 hours, focused on three things: the architecture diagram (does it match the pitch?), the most recent two postmortems (what’s their failure pattern?), and the team page (who actually owns this?). Enough to surface obvious red flags before a partner commits time to a full valuation.

Post-term-sheet. The deep DD. Two weeks, full report, finished before funds wire. This is the standard for a serious lead and the format most of this page describes.

Confirmatory. The closing checklist. The deep DD is already done; this is one final pass on the crown jewels with whatever has changed since. A few days, narrow scope.

The investors who commission this most often: Series A leads doing their first technical pass on the company, PE firms running buy-and-build roll-ups in vertical software, and strategic acquirers checking integration readiness before they sign.

The TDD report is built around decision intelligence, not engineering best practice. Page one is a Red, Yellow, Green scorecard across four pillars: Architecture, Security, Team, Process. Page two is the executive summary, written for the non-technical partner. It answers one question: should we do this deal at this price?

The body looks structurally similar to a founder-side audit. Architecture and scalability, code quality and technical debt, security and compliance. The reframing happens in the language. A finding doesn’t say “the database isn’t sharded.” It says “the database isn’t sharded; sharding takes 6 to 8 engineer-weeks; this is a price adjustment, not a deal-breaker.” Cost-to-fix is in engineer-months, plugged directly into the partner’s model.

For acquirers, I add an integration risks section. Data lineage gaps, API surface, identity and authentication mismatches, anything that delays post-close value creation. That section often does more work than the rest of the report.

What investors specifically ask for, by name: a team and key-person map, a 24-month engineering cost model, an AI maturity read (is the AI moat real or AI-washing?), a compliance gap analysis where the target serves regulated buyers. Each of these gets its own named subsection.

The investor never sees the line-level codebase findings. Those stay with the founder, in a clean room. The investor reads what the findings mean for the 24-month roadmap and the deal structure.

Not legal DD. IP ownership in the abstract, contractor agreements, license compliance reviews go to counsel. I flag obvious red flags (GPL contamination in a proprietary product, missing assignments) but the legal opinion isn’t mine to give.

Not commercial DD. Market size, buyer behavior, win rate against competitors. A different engagement, run by a different kind of advisor.

Not financial DD. I tell you what the engineering org will cost over the next 24 months. I don’t model the company’s P&L.

I draw the boundary clean because most deal-killing surprises come from someone trying to be the all-in-one DD provider and missing the thing that mattered.

The investor-side disclaimer: a TDD is a point-in-time assessment. It identifies known liabilities and quantifies known risks. It doesn’t guarantee future performance. It doesn’t predict defects introduced after close. What it does, when run well, is shrink the surface area of surprise.

Two weeks, same as a founder-side audit. The variable is how the founder cooperates.

Friendly. The norm. The founder wants the deal to close. Read access to the repo, the cloud console, the docs, the analytics. Interviews booked without friction. I work in the open with the team.

Guarded. Sometimes the founder is uncertain about the investor or has something they’d rather not surface. I work around it. Read-only access, fewer interviews, more time on artifacts. The investor gets a slightly less granular report and a written note about the access constraints.

Stalling. A signal. If access is repeatedly delayed past reasonable timelines, I tell the investor immediately. Lack of transparency is a lead indicator of hidden rot. Most deals don’t survive two weeks of stall.

The NDA is tri-party: investor, target, me. The target’s IP is protected. The investor’s deal strategy is protected. My findings go where I’m contracted to send them. In practice, granular code findings stay with the founder; the investor receives the impact analysis, the risk scorecard, and the cost-to-fix estimate. If a code-level finding is deal-impacting, it’s discussed in a clean-room session with the founder present.

When closing pressure compresses the timeline, I run a 5 to 7 day version focused on crown jewels: the proprietary core, the primary data store, the critical security controls. That mode catches deal-killers. It misses long-term optimization opportunities. The report says so on the first page.

Same fixed-fee band as a founder-side audit: €10,000 to €15,000 for a two-week deep DD. The reframing is in the report, not in the price.

The pre-term-sheet dipstick runs €2,000 to €5,000, depending on what you need on it. Useful when you’re triaging deals and don’t want to commit a full DD budget to a maybe. The deep enterprise version (Series C+, multi-entity roll-ups, regulated industries) starts at €25,000 and scales with scope.

Who pays varies. Most often it’s the investor, structured as a transaction expense reimbursed by the target if the deal closes. Sometimes the target pays directly with the investor as the beneficiary, which is fine if the scope letter is clean about the deliverable. Either way, the fiduciary obligation runs to whoever signs the engagement.

Kickoff lands within 48 hours. The DD finishes when the final report is delivered, which is also when the second invoice is due.

Founder side? See /tech-audit. Same engagement, different lens.