Technical due diligence
An independent technical read on a target before you commit capital — from someone who has run engineering at scale, not filled in a checklist.
Every engagement starts with an NDA. Nothing about the target gets discussed before that's signed.
When you need this read
Technical due diligence is the independent read on whether a target's engineering can carry the thesis you are underwriting. Not whether the code is tidy — whether the architecture survives the growth in the model, whether the team can ship the roadmap, and what the risks cost to fix.
You need it when the technology is the asset and you cannot verify it from the data room: a platform claim you have no way to test, an engineering team you are pricing as a capability, a security posture that becomes yours at close, or an AI story that may or may not be a wrapper around someone else's model.
It matters most on growth equity and buyout deals where the technology is load-bearing, and on Series A and B rounds where the question is whether this system reaches the next order of magnitude. The output is a written report and a readout — findings ranked by severity, each with a remediation estimate you can price into the deal.
What's in the report
Six sections, every finding severity-ranked and costed.
Architecture and scalability
What the system actually is, whether it survives the growth the deal assumes, and what breaks first if it does not.
Engineering organization
Who is load-bearing, where the key-person risk sits, and whether the team can execute the roadmap the deal assumes.
Security and data posture
Where customer data lives, who can reach it, and which exposures need remediating before or immediately after close.
AI and model risk
Whether the AI in the product is real, what it depends on, what it costs to run, and where the vendor and data risk sits.
Delivery track record
What the team has actually shipped against what was promised, and what that predicts about the next twelve months.
Risk rating and remediation cost
Every finding ranked by severity with an estimate of what it takes to fix, so technical risk lands in the model, not just the appendix.
Where a checklist audit falls short
Four differences that show up in the findings.
Operated at this scale, not just reviewed it
The read comes from someone who has actually run engineering at the size being diligenced, not a firm that samples code and fills in a template.
Security is the specialty, not an add-on line item
This practice's background is application security specifically, so the data-exposure and access-control findings are a first read, not a bolt-on checklist item.
Findings translate into deal terms
Every risk comes with what it costs to fix, so it drops straight into the model instead of sitting in an appendix nobody prices.
Fluent in what's actually AI and what's a wrapper
Most diligence providers cannot tell the difference. This can, and it is increasingly the finding that matters most.
Who is doing the read
Almost two decades of software experience, including ten years of engineering leadership, most notably at Amazon where Matt led application security reviews for Amazon's retail organization. That meant three security products used by hundreds of thousands of internal stakeholders and security professionals, and a cross-functional team spanning product, security engineering, design, and software engineering.
He administered a $51M+ infrastructure budget with VP-level annual reviews, and held the organization to four nines — 99.99% availability — across every product in scope.
More recently, Matt led engineering teams at Capital One, driving enterprise AI adoption: cross-functional pods embedded with AI workflows that cut delivery time by 50%.
Independently, he helped a Series A company rework its product and engineering roadmap for delivery efficiency while they worked to hit revenue targets ahead of their next raise. He works with companies at seed, Series A, and Series B.
Terms
One engagement, one price. No tiers to compare.
Confirmed with scope and timeline before we start. Never hourly.
Two to three weeks from access. Tell us your deadline on the first call and we'll say honestly whether we can hold the quality to it.
Code access, architecture documentation, and interviews with the target's technical leadership.
A written report with severity-ranked findings and remediation estimates, plus a live readout with your deal team.
NDA signed before any target details are shared, including the name.
No contingent fees, no stake in whether the deal closes. If the engineering is sound, the report says so.
Questions
How fast can you turn one around?
Two to three weeks from access is typical. Tell us your deadline on the first call.
What if the target won't cooperate?
We can work from code and documentation alone. The report says plainly what we could not verify — a weaker read, and you should know that going in.
Do you cover AI and model risk specifically?
Yes, and it is increasingly the finding that matters most: whether the AI is real, what it depends on, and where the vendor and data risk sits.
Can you support the company after close?
Often, yes — usually as fractional or interim CTO work rather than diligence. See fractional CTO.
Do you sign NDAs before seeing target details?
Always, including before the target's name is shared.
None of these fit our situation.
Every deal is a little different. Let's talk — engagements can be scoped to fit.