Technical Due Diligence

Know what's in
the codebase before they do.

Someone is going to read your code with a critical eye — an investor's engineer, an acquirer's team, an enterprise buyer's security reviewer. The only question is whether you've read it that way first.

Audit / Scope ● 2-week
01 Architecture
02 Code Quality
03 Security
04 Infrastructure & Cost
05 Team & Bus Factor
06 IP & Licensing
Architecture Code Security Cost IP
What We Examine

Six places
deals go wrong.

We look where a buyer's technical reviewer looks, and we write it up the way they would — so nothing in their report is new information to you.

Architecture

Whether the system can absorb the next 18 months of roadmap, or whether the plan quietly requires a rewrite nobody has budgeted for.

Code Quality

Test coverage where it counts, consistency, and how much of the codebase a new engineer could safely change in their first month.

Security

Auth, access control, secrets handling, data exposure, and dependency vulnerabilities — the findings that stall a deal at the worst moment.

Infrastructure & Cost

What the platform costs today, what it costs at 10× the load, and which line items scale in a way nobody has modelled.

Team & Bus Factor

Which systems only one person understands, what's undocumented, and what actually happens if that person resigns mid-raise.

IP & Licensing

Who owns the code, whether contractor agreements assign it, and whether any dependency carries a licence your acquirer won't accept.

Deliverables

Five documents,
two weeks.

Written to be forwarded. Every finding carries evidence, an estimated cost to fix, and a plain sentence explaining why it matters to a non-engineer.

Findings Report

Plain-language write-up, evidence attached.

Risk Register

Ranked by likelihood and deal impact.

Remediation Plan

What to fix, in what order, at what cost.

Cost Model

Run-rate today and under projected growth.

Data-Room Summary

A one-pager written for investors.

Timing

Same findings.
Different leverage.

A problem you disclose is a line item. The same problem, discovered by the other side, is a discount.

× Their engineer finds it, in week three of the raise
You find it first, on a timeline you control
× A surprise becomes leverage in someone else's negotiation
A known issue with a costed plan already attached
× Contractor-built code with no assignment on file
Clean IP chain and a dependency licence inventory
× "We'll fix that after close" — priced into your valuation
Fixed beforehand, or disclosed on your own terms
If you're the founder

Run it four to six weeks before you open a data room. That's enough time to fix what's cheap, cost what isn't, and walk into diligence with the answers already written. Buyers increasingly ask for a SOC 2 report alongside it — see SOC 2 readiness.

Need the fixes done too →
If you're the investor

We run the same audit on a company you're considering, and report to you rather than to them — architecture, risk, cost to fix, and how much of the roadmap the current system can actually carry.

Commission a review →
Before The Data Room

No surprises.

Two weeks, fixed scope, five documents. Whatever is in there, you'll be the one who found it — and you'll have a costed plan attached before anyone asks.