Technical Due Diligence

I've been on
both sides of the table

I took JetSmarter through acquisition by Vista Global. I've evaluated acquisitions from the buy side at scale. That experience — not a generic audit framework — is what I bring to M&A technical due diligence, for both sellers preparing their technology and acquirers evaluating a target.

1 exit
JetSmarter → Vista Global
Buy-side
acquisitions evaluated at scale
13+ years
as CTO — I read code, not just reports
Patents
aviation tech IP

Two Sides of the Table

Sell-side and buy-side are different problems

Most due diligence advisors approach both sides with the same audit checklist. They don't. The sell-side problem is about strategic presentation and risk mitigation. The buy-side problem is about seeing through what's been staged.

Sell Side

Making your technology investable

When a startup is approaching an acquisition or investment round, the internal technology team — however strong — often lacks the specific lens of what a buyer's technical diligence team is looking for. What gets flagged, what gets dismissed, and what signals that the business is or isn't ready.

The counterintuitive insight: Not everything that looks like a problem is one, and a "full rewrite" is almost never the right pre-acquisition move. The goal is making the technology investable — not perfect. Sometimes a specific presentation of what you've built, or a targeted fix in the right place, changes the outcome more than months of engineering work.

The other risk: a CTO who is honest about technical debt ("the code is garbage") but doesn't understand what a buyer actually cares about, or a team that takes cheap short-term infrastructure decisions that won't survive a buyer's audit. I help you see your own stack through the acquirer's eyes — and close the gaps that matter.

  • Technology audit from a buyer's perspective — before the buyer sees it
  • Prioritized remediation: what to fix, what to explain, what to leave alone
  • Shaping the automation and IP narrative — why your tech is the core asset
  • Preparing technical documentation and architecture materials for the data room
  • Coaching the CTO through technical Q&A sessions with acquirer teams
Buy Side

Seeing through what's been staged

When a larger organization is acquiring a product or platform, the technology assessment is often the gap between a deal that delivers value and one that creates years of integration headaches. What works in a demo doesn't always represent what's actually in production.

The thing that surprises acquirers: The gap between perceived and actual technical sophistication. A product that looks mature and complex can be running on brittle infrastructure, or worse — high-level functionality built on surprisingly low-level tech that won't survive a migration or scale event.

Beyond the code, acquisitions fail on fit: how does this platform actually integrate with your internal systems? What's the delta between their architecture and yours? And how much of the startup's capability lives in the team's heads rather than the codebase — and what happens to that when the founders leave?

  • Integration complexity assessment: real effort, not optimistic estimates
  • Architecture reality check: what's actually there vs. what's been presented
  • Technical debt quantification with post-acquisition cost impact
  • Security, deployment, and compliance exposure identification
  • Cultural and engineering team fit — who stays, who leaves, what walks out

The Assessment

What I actually look at

A technical due diligence report should tell you something a junior developer couldn't. Here are the areas I go deep on — with a focus on what matters for post-close success, not just a clean checklist.

Architecture & Scalability

  • System design and component boundaries
  • Scale ceiling — where does it break?
  • Perceived vs. actual complexity
  • Single points of failure
  • Cloud infrastructure and operational maturity

Codebase & Technical Debt

  • Code quality and maintainability
  • Test coverage and CI/CD pipeline
  • Dependency risk (outdated, abandoned, risky libraries)
  • Tech debt inventory with remediation cost estimates
  • Documentation — is knowledge captured or in people's heads?

Security & Compliance

  • Authentication, authorization, and data access controls
  • Data handling and privacy posture (GDPR, CCPA, HIPAA)
  • Vulnerability exposure and incident history
  • Third-party and vendor security dependencies
  • Compliance gaps that create post-close liability

Integration & Ecosystem Fit

  • API surface — what connects to what, and how cleanly
  • Integration effort with acquirer's existing stack
  • Platform differences that create migration risk
  • Data migration complexity and data quality
  • Vendor lock-in and licensing exposure

IP & Proprietary Assets

  • Ownership of code, algorithms, and datasets
  • Patent landscape and infringement risk
  • Open source license compliance
  • Trade secret and confidentiality posture
  • Automation and tech as the actual value driver

Team & Engineering Culture

  • Key person dependencies — who is the codebase?
  • Team structure and retention risk
  • Engineering culture vs. acquirer's culture
  • Founder involvement in technical decisions
  • Hiring pipeline and team scalability

How It Works

Fast, structured, decisive

M&A timelines don't wait. I work fast and deliver a clear, actionable output — not a 100-page report that nobody reads. The goal is to equip decision-makers with exactly what they need, nothing more.

01
Day 1

Scope & Access

Understand the deal context, timeline, and what decision this assessment needs to inform. Get access to code repositories, architecture documentation, infrastructure, and the technical team for Q&A sessions.

02
Days 2–5

Deep Technical Review

Code review, architecture analysis, infrastructure audit, security assessment, and structured interviews with the engineering team and CTO. I'm looking at what's there, not what's been presented.

03
Days 6–7

Findings & Risk Prioritization

A clear written report: critical risks, moderate risks, and non-issues — each with context and post-close implications. No fluff. Findings are organized by what matters to the deal, not by what was easiest to audit.

04
Day 8

Readout & Q&A

A direct conversation with the decision-makers — board, deal team, or executive sponsors. I present the findings, answer questions, and give a clear recommendation on technical fit and risk exposure. If needed, I stay available through close.

Tighter timelines?

Compressed deal timelines happen. A focused 3-day rapid assessment covering the highest-risk areas is available when there isn't time for a full review. Scope is narrower but the findings are equally direct. Get in touch to discuss.


Who This Is For

The situations where I add the most value

Startups preparing for acquisition

You're in conversations with potential acquirers and want to know what they'll find — and fix it before they do. Or you want someone to help you tell the technology story in the way that lands.

PE and VC firms

You're evaluating a technology-heavy target and need a fast, credible technical opinion from someone who can actually read the code — not just interview the CTO.

Corporate acquirers

Your internal team knows your stack but doesn't know the target's. You need a neutral outside perspective that goes deep on integration complexity and post-close risk.

Founders considering a strategic exit

You haven't started the formal process but want to understand what shape your technology is in, what a buyer would flag, and how to spend the next 12 months wisely.


Let's Talk

M&A moves fast — so do I

Tell me where you are in the deal timeline, which side you're on, and what the decision pressure looks like. I'll tell you honestly if and how I can help, and we can scope it from there.