When you buy a software business, the technology usually is the asset. Financial due diligence tells you what the business earned. Technical due diligence tells you whether it can keep earning once you own it, and what it will cost to get there.

In short: a technical due diligence (tech DD) is an independent review of a target's architecture, code, security, IP, cloud costs, team, and processes. It ends with a clear go / go-with-conditions / no-go recommendation, a risk register with remediation costs, and concrete input for the price, the purchase agreement, and your first 100 days.

Large firms run tech DD over months with big teams. Private equity funds, search funds, holdcos, and individual buyers doing smaller deals need something different: fast, fixed in scope, and focused on what actually moves the deal. This guide explains what that looks like.

Match the Depth to the Deal

Not every deal needs the same depth. Tech DD typically comes in four levels, matched to the deal stage and the size of the risk:

  • Red-flag screen (pre-LOI). A quick go/no-go based on a founder interview, a look at the architecture, and a handful of targeted checks. Output: a short memo listing deal-breakers and the questions to ask next.
  • Lite assessment (post-LOI). For simple products or smaller deals. Covers the highest-risk areas in depth and the rest at a high level.
  • Standard assessment (post-LOI). The full process below, across all nine areas. The right default for most software acquisitions.
  • Deep dive (post-LOI). For larger or more complex targets: multiple products, regulated data, heavy AI use, or a planned platform integration after the deal.

The Process: Six Phases

A well-run standard assessment follows roughly these phases.

1. Scoping and kickoff

NDA signed, then a short call on your investment thesis and your main worries. Are you buying for growth, for cashflow, or to merge with a platform company? The answer decides where to look hardest. A data request list then goes to the seller.

2. Document review

Architecture docs, cloud bills, tech vendor contracts, IP assignment agreements, security policies, past incidents, and any previous audits or pen tests. Missing documents are findings too.

3. Interviews

Four to six sessions with the founder or CTO, lead engineers, DevOps, and product. Interviews reveal what documents hide: who really knows how the system works, what everyone is afraid to touch, and what the team would rebuild if they could.

4. Hands-on assessment

With read-only access to the code, CI/CD, cloud console, and monitoring, the assessor checks the real systems. Automated scans for open-source licenses, vulnerable dependencies, and secrets committed to code, followed by a hands-on review of what the scans flag. Claims from the interviews get checked against reality.

5. Synthesis

Findings become a risk register: severity, likelihood, cost to fix, and time to fix. Then each risk is translated into what it means for the deal.

6. Readout

The report is delivered and walked through in a working session with the deal team, so you can challenge the findings and decide what to take into negotiation.

What Gets Assessed: Nine Areas

Each area answers a question a buyer actually cares about.

1. Architecture and scalability

Can it handle 3–5x growth without a rewrite? Where the bottlenecks are, what breaks first, and whether the design fits the growth plan in your model.

2. Code quality and tech debt

What will it cost to keep shipping? Tech debt is normal. What matters is whether it slows the team down today and how much it costs to pay down, in engineer-months rather than adjectives.

3. Security and compliance

Is there a breach or a compliance gap waiting to happen? Access control, secrets management, pen-test history, backups that have actually been restored, and fit with SOC 2, GDPR, CCPA, or sector rules like HIPAA and PCI where relevant.

4. Intellectual property and open source

Does the company actually own what you're buying? IP assignments from founders, employees, and especially contractors, plus copyleft licenses (GPL, AGPL) that could force the company to publish its source code.

5. Infrastructure and cloud cost

What does it cost to serve a customer, and where is the margin leaking? Cloud spend relative to revenue, how it scales, single points of failure, and quick savings you can bank after closing. Cloud waste is common in small companies, and every dollar saved goes straight to EBITDA.

6. Team and key-person risk

What happens if one person leaves? Often the biggest risk in founder-led businesses. Who holds the knowledge and the production credentials, how likely they are to stay after the deal, and how hard it would be to hire their replacement.

7. Engineering process

Can the team ship reliably? How code moves from a laptop to production, release cadence, testing, incident handling, and on-call. A team that deploys by hand on Friday nights is a risk, whatever the code looks like.

8. AI positioning

Does AI make this business stronger, or is it about to eat it? Most tech DD skips this, but it is now central to valuation. Is the product AI-supercharged (AI lowers costs or widens the moat) or AI-resistant (proprietary data, workflows, or relationships that a model can't replicate)? Or is it exposed to a competitor with a prompt? For AI features: dependency on a single model vendor, LLM cost per customer, and rights to the training data.

9. Product and roadmap

Is the roadmap in the model actually buildable? Whether the planned features are feasible with the current team and stack, and how much investment they really need.

What a Good Tech DD Report Contains

Whoever runs it, insist on a report you can act on. It should include:

  • Executive summary: a red/amber/green rating per area and a clear go / go-with-conditions / no-go recommendation. Two pages a decision-maker will actually read.
  • Risk register: every finding with severity, likelihood, estimated cost to fix, and time to fix.
  • Deal implications: what to take into negotiation (see below).
  • 100-day technical plan: the fixes, hires, and quick wins to prioritize after closing.

Red Flags That Show Up Again and Again in Small Deals

  • The founder is the only one who can deploy, and holds every production password.
  • Core code was written by contractors who never signed an IP assignment.
  • GPL code in a product shipped to customers, or AGPL code in a SaaS product.
  • Cloud costs growing faster than revenue, with nobody looking at the bill.
  • Backups exist, but nobody has ever tried restoring one.
  • API keys and database passwords committed to the repository.
  • The "AI feature" is a thin wrapper on one vendor's API, with no fallback and no cost controls.
  • No staging environment. Changes are tested in production.
  • A big customer depends on custom code or a promised SLA that isn't in the contract list.

None of these automatically kills a deal. Most are fixable. The point is to know about them before you sign, and to price them in.

How Findings Shape the Deal

A good tech DD report doesn't just list problems. It tells you what to do with them:

  • Price adjustment: known remediation costs come off the price, or into an escrow or holdback.
  • Specific reps and warranties: on IP ownership, open-source compliance, security incidents, and data handling.
  • Conditions before closing: sign the missing IP assignments, rotate exposed credentials, hand over admin access to accounts.
  • Retention for key people: earnouts, equity, or transition agreements for whoever holds the critical knowledge.

How to Prepare as a Buyer

The assessment goes faster, and gets better, if you ask the seller for these early:

  • An architecture overview, even a whiteboard photo
  • Read-only access to the code repositories, CI/CD, and cloud console
  • The last 12 months of cloud and SaaS bills
  • Security policies, pen-test reports, and any compliance certifications
  • Org chart, including contractors and agencies
  • IP assignment agreements for everyone who wrote code
  • Customer contracts with SLAs or custom technical commitments
  • A list of third-party services and open-source components
  • Incident history for the last year or two

Also share your investment thesis with whoever runs the assessment. "We plan to double the sales team" and "we plan to merge it into our platform" lead to very different assessments.

What Technical Due Diligence Is Not

It isn't a legal, financial, or tax opinion. It flags issues such as missing IP assignments for your lawyers and margin-eating cloud costs for your financial advisors. It isn't a full penetration test either, although one can be added through a specialist partner when the risk justifies it. And it isn't a hunt for perfect code. No company has that. The question is whether the technology supports the deal you're planning.

Get in touch to discuss a deal you're evaluating.