Technical due diligence before acquiring a software company

Technical due diligence for software acquisitions answers one question: what are you actually buying? Not what the pitch deck says. Not what the demo showed. What exists in the codebase, the team, and the infrastructure right now, and what it will cost to get it where you need it to be.

We have conducted more than 178 technical audits at madewithlove, working regularly alongside Belgium's B2B SaaS investor community (Volta Ventures, Capricorn, PMV, Fortino Capital, Smartfin, ...) and PE acquirers across Europe. Roughly a quarter of those engagements were M&A: PE firms, strategic acquirers, and holding companies evaluating software targets before signing. The rest were pre-investment audits for VCs, internal health checks, and scale readiness assessments. The dataset is large enough to show patterns, and the patterns are remarkably consistent.

This piece covers what acquisition-focused technical due diligence actually involves, what it typically finds, and how it differs from the financial DD you already have covered.

What does technical DD cover in a software acquisition?

A technical audit for an acquisition evaluates six dimensions. Financial DD tells you what the company earns. Technical DD tells you whether the thing that earns it will keep working.

Team

Composition, role clarity, key person dependency. In 78% of our audits, one person controls architecture, code review, infrastructure, and product direction simultaneously. For an acquirer, this is a transfer risk: if that person leaves post-acquisition, the asset degrades. In M&A audits specifically, the question shifts from "can this team improve?" to "can someone else run this?"

Architecture and infrastructure

Scalability ceiling, tech stack coherence, dependency risk. Is the product built to handle the growth the acquisition thesis assumes? Or will it require a significant re-architecture investment within 18 months?

Processes

How the team ships. CI/CD maturity, deployment frequency, testing coverage, incident response. 52% of the companies we audit deploy manually or infrequently. One team required a physical drive to the office to restart production servers. These aren't just inefficiencies. For an acquirer integrating a team into a larger organisation, process maturity determines how fast the integration can move.

Documentation

The scaling blocker nobody expects. 94% of our audits flag documentation debt. Not "the README is outdated." Knowledge that exists only in people's heads. Architectural decisions made verbally and forgotten. Onboarding that depends on the CTO sitting next to the new hire. For an acquisition, poor documentation means every departure takes institutional knowledge with it.

Security and compliance

Secrets management, access controls, data handling, licence compliance. 47% of audited companies have credentials committed to their codebase. 39% have never reviewed their open-source licence obligations. For M&A, licence compliance can stall a deal: a GPL dependency in a proprietary product creates a legal exposure that needs resolving before close.

AI posture

New dimension as of 2026. Not "does the product use AI?" but "is AI embedded in how the team works?" A team that hasn't adopted AI tooling by 2026 is signalling something about their learning culture and competitive positioning. Financial DD firms cannot assess this. It requires someone who understands what modern engineering practice looks like.

The five technical risks that restructure deals

These are the findings that change deal terms. Not every audit surfaces all five. But when they appear, they move numbers.

1. Key person as single point of failure.

In 78% of audits, the entire technical operation depends on one individual. In M&A context, that person often has emotional ties to the product and may not stay post-acquisition. We have seen CTOs who haven't taken time off in two years. Infrastructure engineers who personally own the cloud servers, making the company unable to operate if they leave. One company's CTO was also the only person with admin access to hosting, source control, and project management tools. The transfer risk is not theoretical.

2. No automated testing.

87% of audited companies lack meaningful automated testing. Manual QA dominates even at Series A. For an acquirer planning integration or scaling, this means every change to the codebase carries unquantified risk. The cost of confidence goes up. Shipping slows down. And the "move fast" narrative that justified the acquisition price starts to look less credible.

3. Architecture that doesn't match the growth thesis.

10% of audits flag microservices regret: more microservices than engineers, Kubernetes for a five-person team. The reverse is more common: a monolith approaching the point where it needs to be decomposed, but the team has neither the experience nor the capacity to do it. An acquirer pricing in 3x growth needs to know whether the architecture can support it, or whether a significant re-architecture investment is required first.

4. Product management absent.

72% of audited companies have rudimentary or missing product management. The CTO doubles as product owner. Prioritisation is instinct. 52% track no product metrics at all. Nobody can tell you which features drive retention, because nobody is looking. For an acquirer, this means the product roadmap is built on intuition, not evidence. The asset you're buying may be building features into the void.

5. Security posture as liability transfer.

Credentials in the codebase (47%), untested disaster recovery (29%), GDPR gaps (22%). One healthcare audit surfaced 44 security risks including patient data in plaintext and public storage buckets for blood lab results. When you acquire a company, you acquire its security posture. Every unpatched vulnerability, every compliance gap, every credential committed three years ago and never rotated becomes your problem on day one.

How M&A technical DD differs from startup DD

The framing changes entirely. A pre-investment audit asks: can this team get better? An acquisition audit asks: can someone else run this?

The practical difference: an M&A audit produces asset definition, not just risk assessment. Investors regularly do not know what they are actually buying. The financial DD tells them the company earns EUR 2M ARR. The technical DD tells them that EUR 2M depends on one person who hasn't taken a holiday in two years, a codebase with no tests, and an architecture that will need rebuilding within 18 months of 3x user growth. Those facts change the price.

The five-step process: how a technical DD engagement works

Step 1: Scope alignment (Day 1)
Not a questionnaire. A conversation. What does the acquirer need to know? What are the deal-specific concerns? M&A audits require different emphasis than pre-investment audits: transfer risk, integration complexity, and regulatory exposure take priority over team coaching potential.

Step 2: Discovery (Days 2-3)
Access to codebase, infrastructure, CI/CD pipelines, documentation, and project management tools. Initial team interviews with CTO, lead developers, and product owners. The discovery phase surfaces the concerns that shape the deep dive.

Step 3: Deep dive (Days 4-7)
Detailed assessment across six dimensions. Code review, architecture analysis, security scan, process evaluation. M&A audits include explicit transfer risk assessment: what happens to the product if key people leave? What knowledge exists only in someone's head?

Step 4: Synthesis (Days 8-9)
Cross-referencing findings against our 180-audit benchmark. How does this company compare? Are the concerns standard for its stage, or are there structural issues that affect valuation?

Step 5: Report delivery and debrief (Day 10)
Executive summary for the investment committee. Full technical report with evidence. Action roadmap prioritised by risk and effort. Debrief call with the acquirer and, if appropriate, the target's technical leadership.

A typical M&A engagement takes 10 business days from access to report delivery.

How to choose a technical DD firm

Three criteria separate useful DD from expensive reassurance.

Audit methodology, not just technical expertise.
Any senior engineer can read code. A DD firm needs a structured methodology that produces comparable, defensible findings across companies. Ask: how do you score findings? How many audits have you conducted? Can you benchmark this company against your historical data?

Sector experience in software companies.
Financial DD firms (Big 4) assess software as a balance sheet item. Technical DD firms assess software as an operational system. The concerns are different: a financial auditor checks licence compliance; a technical auditor checks whether the architecture can handle 3x growth. These are complementary, not competing. You need both.

Collaboration tone.
This sounds soft, but it predicts audit quality. Teams that feel judged get defensive. Defensive teams hide problems. The best DD firms create an environment where the target team is honest about their weaknesses, because the findings are more useful when they are. In all audits, the most actionable reports consistently came from engagements where the target team felt helped rather than interrogated.

What a good DD report looks like

A DD report for software acquisitions should contain four deliverables.

The executive summary gives the investment committee a go/no-go signal in two pages. How does this company compare to the benchmark? What are the critical risks? What would it cost to fix them? Investors and board members read this. Engineers read the rest.

The full technical report covers all six dimensions with evidence. Not opinions. Screenshots of the codebase, infrastructure diagrams, process documentation (or its absence), security scan results. Each finding is scored by severity and linked to a specific business risk.

The action roadmap prioritises findings by risk and effort. Quick wins (secrets rotation, CI/CD setup) versus structural investments (architecture redesign, team restructuring). The roadmap answers: if we acquire this company, what do we need to fix first, and what will it cost?

The benchmark comparison places the company against our dataset. An average SaaS company has 15-20 concerns. Fewer than 10 puts you in the top quartile. More than 25 means foundational gaps across the board. The benchmark turns abstract findings into relative positioning.

How much does technical DD cost?

Technical DD for a software acquisition typically costs EUR 15,000-30,000 for a 10-day engagement, depending on the complexity of the codebase and the number of team interviews required. Larger targets with multiple products or distributed teams may require 15-20 days and proportionally higher investment.

For context: the cost of a technical DD engagement is typically 0.1-0.3% of the acquisition price. The cost of discovering a critical technical issue post-acquisition is orders of magnitude higher. One company in our dataset needed a complete infrastructure rebuild within six months of acquisition because the DD process had only covered financial and legal aspects. The rebuild cost more than the entire technical DD would have.

Frequently asked questions

What is the difference between technical DD and a code audit?
A code audit reviews the codebase. Technical DD evaluates the entire technical operation: team, architecture, processes, documentation, security, and AI posture. Code quality is one input, not the whole picture.

When should technical DD happen in the acquisition process?
After the LOI is signed and before final terms are agreed. The findings should inform valuation, not just confirm a decision already made. Starting too late means the DD becomes a formality rather than a decision input.

Can we do technical DD internally?
You can, but the value drops significantly. Internal teams lack the benchmark data (how does this company compare to 180 others?), they may lack M&A-specific experience, and they carry political constraints that an external firm does not. The CTO of the acquiring company has opinions about architecture. An independent firm has data.

What if the target company refuses access?
This happens occasionally, particularly with founder-led companies who feel protective of their codebase. The refusal itself is a finding. In our experience, the companies most reluctant to open up are the ones with the most to discover. Work with the investor or acquirer to negotiate access as a condition of the deal.

How does technical DD interact with financial DD?
They are complementary. Financial DD assesses what the company earns. Technical DD assesses the sustainability and scalability of the thing that earns it. Security findings (licence compliance, data handling) often have direct financial implications. The best outcomes happen when financial and technical DD teams share findings during the process rather than at the end.

Do you assess AI readiness?
Yes. As of 2026, AI posture is a standard dimension. We evaluate whether the team has embedded AI tooling in their development workflow, whether the product's AI features (if any) are built on sustainable architecture, and whether vendor dependencies create fragility. A team that hasn't adopted AI tools by 2026 is signalling something about their learning culture that matters for post-acquisition integration.

What happens after the report?
The report is a decision input, not the end of the relationship. Acquirers often need support implementing the action roadmap: addressing critical security gaps, restructuring the team, or providing interim technical leadership during the integration period. These follow-on engagements are separate from the DD itself.

Is the process different for cross-border acquisitions?
The methodology is the same. The emphasis shifts. Cross-border acquisitions add complexity around data residency (GDPR, local regulations), team location and timezone management, and language barriers in documentation. 29% of our audits flag non-English documentation as a scaling barrier. For a cross-border acquirer, this becomes an integration cost.