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.
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.