Technical Due Diligence
I read the codebase, the infrastructure, and the team behind them, then tell you what you are actually buying. Architecture that will not hold the plan, a key engineer nobody can replace, a cloud bill on a bad curve, or a product where most of the code came out of an LLM and no one on staff can debug it. One to two weeks, day rate or fixed scope, report in your hands before the investment committee meets.
Technical due diligence is an independent review of a target company's software, infrastructure, and engineering team before an investment or acquisition closes. Oleg Sotnikov runs these reviews for funds and acquirers: architecture and scalability, code quality and how much of the codebase was AI-generated, key-person risk, infrastructure cost trajectory, security posture, and IP and licensing. The deliverable is a written report with red flags, deal risks priced by remediation cost, and a 100-day plan for the first quarter after close. Engagements run one to two weeks on a day rate or a fixed scope agreed before the work starts.
What the Review Covers
Six lenses on the same target. I rank findings by what they do to the deal, not by how interesting they are to engineers.
Architecture and scalability
Whether the system survives the growth the deal model assumes. I look at the data model, coupling between services, single points of failure, and what serving 10× the current traffic would actually cost.
Code quality and AI-generated code
Test coverage, review discipline, and how much of the codebase came out of an LLM. Vibe-coded systems can look finished and still have nobody who can debug them at 2am. I check provenance, internal consistency, and whether the team can maintain what it shipped.
Team, bus factor, and key-person risk
Who actually knows the system. I map commit history against the org chart, find where the bus factor is one, and name the people whose departure would stall the roadmap for a quarter.
Infrastructure spend and cost trajectory
What the platform costs today and what it costs at the volumes in the plan. Cloud, LLM tokens, per-seat tooling: unit economics that look fine at current scale sometimes invert at 5×.
Security, compliance, and AI governance
Secrets handling, access control, dependency CVEs, and the real state of SOC 2 or GDPR work if the buyer needs it. For AI products: which data reaches which model provider, what gets logged, and who signed off on it.
IP, licensing, and dependency hygiene
Who owns the code, contractors and departed founders included. I check license obligations across the dependency tree, copyleft exposure in anything shipped to customers, and whether the IP assignment paperwork matches what the git history shows.
How It Runs
Scope and access
We agree what the deal needs answered and how deep to go. NDA first, on your paper or the target's, then read-only access to repositories, cloud and billing consoles, the issue tracker, and whatever architecture documentation exists. Nothing I do touches production.
Review and interviews
I read the code and the infrastructure, then talk to the CTO and the engineers who built it. Interviews are where documentation gets checked against reality, and most serious findings start as a gap between the two. I work async-first from US Pacific, so written updates land overnight for a UK deal team.
Report and walkthrough
A written report laid out the way US and UK deal teams read one: red flags first, then each risk with the evidence behind it and an estimate of what fixing it costs in money and months, then a 100-day plan for the first quarter after close. We finish on a call where your team can push back on any finding.
Who's Doing the Work
- 25+ years in IT, 7 patents and 45+ certifications — the technical judgment in the report is mine, not a junior's working from a template
- I have run due-diligence-style technical reviews for accelerator cohorts and investor presentations
- Founder on both sides of the table — 9 startups, 2 exits — so I know which data-room answers sound good and still need checking
Frequently Asked Questions
What does technical due diligence include?
A technical due diligence review covers architecture and scalability, code quality and its provenance, the engineering team and its key-person risk, infrastructure and LLM spend, security and compliance posture, and IP and open-source licensing. Some clients call it tech due diligence or software due diligence; the checklist is the same. The question behind all of it is whether the technology can carry the plan the deal is priced on, and what it costs to fix the parts that cannot. Findings come back ranked by deal impact, with remediation effort attached to each one.
How long does technical due diligence take?
Typically one to two weeks, depending on codebase size and scope. A single-product SaaS with one repository and a small team sits at the short end; a multi-service platform that has already absorbed an acquisition takes the full two weeks. When a deal process needs an earlier read, I send the red flags within the first few days and the full report after.
What access do you need, and do you sign an NDA?
An NDA comes first, and I sign the fund's or the target's paper rather than insisting on my own. After that I need read-only access to the code repositories, the cloud and billing consoles, the issue tracker, and any architecture or security documentation, plus an hour or so each with the CTO and one or two senior engineers. Nothing changes in the target's production systems during the review.
Can you assess AI products and AI-written code?
Yes, and in 2026 it is a standard part of the review rather than an add-on. I measure how much of the codebase was generated by an LLM, whether it is coherent enough to maintain, and whether anyone on the team can debug it under pressure. For AI products I also review model routing and token economics, prompt and data handling, evaluation practice, and what the provider terms permit. The platform I run processes over 11 billion tokens a month, so I assess it from operating experience.
What does the technical due diligence report look like?
A written document structured for a deal team rather than an engineering audience. It opens with red flags and a summary a partner can read in five minutes, then covers each area with findings, the evidence behind them, and an estimate of the cost and time to remediate. It closes with a 100-day plan for the first quarter after close. We walk through it together on a call, and I stay reachable for follow-up questions through the rest of the process.
How much does technical due diligence cost?
Engagements are priced per deal, either on a day rate or as a fixed scope agreed before any work starts. There is no list price, because a two-repository micro-SaaS and a fifteen-service platform are not the same job. You get the number and the scope in writing up front, and it moves only if you widen it. If what you need after close is someone in the CTO chair rather than a one-off review, the retainer rates are on the pricing page.
Rate the deal first — free scorecard
Sixteen questions across architecture, delivery, team, and security. They put a number on a target's technology risk before you commit to full diligence.
Open the tech DD scorecardKnow What You're Buying
A scoping call takes thirty minutes: the deal, your worries, the access that exists. You leave knowing what the review would cover, how long it takes, and what it costs.
If you screen deals in-house, the technical due diligence checklist I work from is free on this site.
Related reading
Architecture risk, engineering-team risk, and what AI-written code does to a codebase.
