Technical due diligence

Technical due diligence, written for the people signing the cheque.

Before a round closes or an acquisition completes, someone has to answer whether the technology can carry the plan the deal is priced on. We review the architecture, the codebase, the infrastructure and the team, then hand over a report that states the risks, ranks them, and puts a number on fixing each one.

When funds call us

  • The team is impressive and we cannot independently verify what they have built.

  • The plan assumes ten times the load. Nothing in the current system suggests it will get there.

  • One engineer appears to understand the whole platform, and we need to know how bad that is.

What the review covers

Architecture and scalability

Whether the system as built can reach the numbers in the model, and what has to be rebuilt if it cannot. We separate what breaks at 10× from what breaks at 100× — those are very different price tags.

Code quality and technical debt

Where the debt is concentrated and what it costs per shipped feature. Debt in a stable, rarely-touched module is not a finding; debt on the critical path is. We report the difference rather than a raw score.

Security and compliance exposure

Authentication, secret handling, data flows, dependency risk and third-party exposure, assessed against the obligations the business actually carries in the markets it sells into.

Team, ownership and key-person risk

Who knows what, how much of the system has exactly one person who understands it, and how quickly a replacement could get productive. Usually the finding with the largest effect on valuation.

Delivery capability

How long a change takes from decision to production, and how often it goes wrong. A team that ships weekly and a team that ships quarterly present the same roadmap very differently.

Remediation cost and sequence

Every material finding gets an estimate in engineering months and a position in a sequence, so the number can go into the model instead of into a footnote.

What you receive

  • A written report structured for an investment committee, not for engineers
  • Findings ranked by impact on the thesis, each with an estimated remediation cost
  • A red-flag summary you can read in five minutes
  • An architecture and dependency map of the system as it actually is
  • A call with your team and, if useful, with the target's engineers

Related work

Questions we hear from funds

How long does a diligence engagement take?
Typically one to three weeks depending on system size and access. We can usually start within five to seven business days, and we will say up front if your timeline is not realistic rather than deliver a thin review on schedule.
How much access do you need from the target?
Read access to the repositories, a walkthrough of the infrastructure, and interviews with two or three engineers. We can work from a narrower scope, and the report states plainly which conclusions were limited by access.
Do you work under NDA?
Always, and we are equally happy to sign the target's. Access is scoped to what the review requires and revoked when it ends.
Can you review a company you might later work with?
We disclose any prior relationship before the engagement starts, and we do not pitch remediation work to a company we have just assessed for you. A diligence report is only useful if the reviewer had nothing to sell.
What if the finding is that everything is fine?
Then that is the report. A clean review with evidence behind it is a legitimate and useful outcome, and we would rather deliver one than manufacture concerns to justify the fee.

Diligence coming up?

Tell us the deal timeline and how much access you have. We reply within a business day with a scope, a fee and an honest read on whether the timeline is achievable.

Ready when you are

Have a project in mind? Let's talk about it.

Send us a short description of what you're building or what's broken. We'll reply within a day with honest thoughts on scope, approach, and whether we're the right fit.