What Technical Due Diligence Actually Requires
Most acquirers rely on financial models and market analysis. They look at revenue, churn, and TAM. But the technology — the thing they're actually buying — gets a surface-level review at best.
It's an understatement to say this can lead to problems. In one notable incident, an acquirer discovered that the video demo of the system was faked. The large codebase written by a large team of contractors did... nothing. It was a terrible UI that worked like a child's cash register toy. It did fun things on screen and ultimately moved no data. The entire codebase was theater.
I've watched deals close on apps that crashed every ten minutes, on codebases that couldn't support the growth the business plan assumed, and on teams that looked great on paper but couldn't ship without the one engineer who was about to leave.
I've cleaned up acquired codebases, acqui-hired teams, and helped both investors and operators perform due diligence on acquisition targets across mobile, SaaS, IoT, and other verticals. The technical evaluation is the part that most deal teams get wrong — or skip entirely.
When the Codebase Is AI-Built
A new diligence question arrived over the last two years: how much of this codebase did AI write, and who on the team actually understands it?
More targets every quarter were built partly or mostly by AI — a founder directing coding agents instead of hiring the contractor team the last generation of targets used. That isn't a defect. Well-directed AI development with review discipline behind it produces maintainable software faster and cheaper than the contractor model it replaced. The diligence question is whether the discipline existed.
The faked-demo story above has an AI-era twin: a codebase that looks complete — clean structure, confident naming, thorough-seeming tests — with no one who can explain why any of it works. AI is exceptional at producing the surface features of finished software. On an AI-built target I check three things beyond the standard review:
- Provenance and review discipline. The commit history tells the story: changes that arrived as reviewed, tested increments — or wholesale commits nobody read. Tests written by the same unreviewed session that wrote the bugs count as decoration, not coverage.
- Whether the harness is part of the deal. The scaffolding around the AI — project instructions, evals, the accumulated context that makes the system maintainable — is often where the engineering value actually lives. If it exists, it should be in the asset list. If it doesn't, you're buying output without the means of production.
- Bus factor, AI edition. Can anyone besides the founder direct the next change? A one-person shop with AI leverage can look like a ten-person team right up until that one person leaves.
What I Evaluate
Codebase Health. Architecture, test coverage, dependency hygiene, deprecated APIs, build warnings, and whether the code is maintainable by someone other than the person who wrote it. I've reviewed codebases in Swift, Kotlin, Python, TypeScript, and Go. The language matters less than the engineering discipline behind it.
Infrastructure & Operations. CI/CD pipelines, crash rates, monitoring, deployment processes, and production reliability. A slick demo doesn't prove anything. I want to see what happens when the system is under load, when a deploy goes sideways, and how long it takes the team to recover.
AI Readiness. If the target uses AI — or the acquirer plans to integrate AI post-acquisition — I evaluate the data pipeline, model governance, IP exposure, and whether the AI actually does what the pitch deck claims. Most companies using AI have significant intellectual property gaps they haven't addressed.
Team Capability. When an acquisition involves hiring talent, take special care. I've seen acqui-hires go south when the acquiring company lacks the expertise to evaluate the team they're absorbing. A polished app doesn't prove engineering competence. Mistakes like this can take years to surface because there are no experts to diagnose why the team can't ship.
Business Metrics. User reviews, revenue integrity, App Store Optimization, conversion funnels, and whether the growth numbers are repeatable or a one-time spike. An acquisition might depend on an expectation of improvement through better pricing, marketing, or funnel optimization — but only if the technology can support it.
Who This Is For
Investors evaluating a target. You need someone who can tell you whether the technology is an asset or a liability before you sign the LOI. I give you the honest assessment your deal team can't.
Operators planning an acquisition. You need to know what you're inheriting — the integration cost, the technical debt, the team gaps. I've helped companies plan post-acquisition integration across multiple technology stacks.
Board members with concerns. Revenue is soft, releases are late, and nobody's giving you a straight answer about the technology. I'll tell you what's actually happening beneath the surface.
I maintain 3-5 active advisory roles at a time. If you'd like help evaluating a technology acquisition or investment, let's schedule a conversation.