What Technical Due Diligence 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 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
A technical finding is only useful once it resolves to a number or a term. Every area below comes back to the same three questions: does this move the price, does it change the deal terms, and what does it cost to fix after close.
Codebase Health. What matters is whether this codebase can carry the plan you're buying it for, and what it will cost to get there. That comes out of architecture, test coverage, dependency hygiene, deprecated APIs, build warnings, and whether anyone but the original author can maintain it. I've reviewed codebases in Swift, Kotlin, Python, TypeScript, and Go; the language matters less than the engineering discipline behind it. Where it's useful, the assessment can extend into an engineering plan with estimates you can carry into your model.
Infrastructure & Operations. The question is whether this system can carry the growth your business case assumes, or whether year one gets spent rebuilding instead of shipping. Answering it means looking at CI/CD pipelines, crash rates, monitoring, deployment processes, and production reliability. A slick demo proves little. 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 you plan to integrate AI post-acquisition — the exposure that matters is ownership: whether the data pipeline, model governance, and IP position survive contact with your counsel, and whether the AI does what the pitch deck claims. Most companies using AI have significant intellectual property gaps they haven't addressed. Model output nobody clearly owns is sitting in the asset list you're paying for, and it belongs in the valuation.
Team Capability. When an acquisition involves hiring the team, the decisions that matter are who you need to keep and what it takes to keep them. I can give you the data behind those calls: which engineers carry the knowledge the system depends on, where capability is concentrated, and what happens to delivery if a given person walks. Acqui-hires go south when the acquiring company lacks the expertise to evaluate the team it's absorbing, and a polished app doesn't prove engineering competence. Problems like these take years to surface, because there's nobody in the building who can diagnose why the team can't ship.
Business Metrics. An acquisition often prices in improvement from better pricing, marketing, or funnel work, and that upside is only real if the technology can support it — which makes it a technical question worth pricing as one. I look at user reviews, revenue integrity, App Store Optimization, conversion funnels, and whether the growth numbers are repeatable or a one-time spike.
Scope and Timing
Deal timelines don't wait, so the engagement is sized to the decision in front of you.
At the light end, that's a single hour-long interview with the target's technical lead — often enough to tell you whether a concern is real and where to look next. At the other end, it's a multi-week investigation of an entire platform, with the codebase, infrastructure, team, and AI exposure all in scope. Most engagements land somewhere between the two.
If you're working inside an exclusivity window, say so when you reach out and I'll tell you what fits the time you have.
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.