Technical due diligence for deals

Atlassian's stock is down roughly 45% in 2025 on fears that AI is eating its collaboration moat, even as Rovo adoption reframes the bear case (MarketBeat). That swing is a useful reminder for anyone buying software companies right now: a target's technical position can revalue itself in a single quarter. Generic audits do not catch that. Technical due diligence tied to the investment thesis does.

Most deal teams still treat technical due diligence as a checklist exercise run by generalists who leave the day the SPA is signed. That is where value leaks. The engineers who understood the codebase, the architecture debt, and the AI exposure are gone before anyone has to actually fix anything.

What is technical due diligence

Technical due diligence is a pre deal assessment of a target company's software, architecture, engineering team, and technology risk, scoped to the specific investment thesis. It covers code quality, scalability, security, IP ownership, AI and data posture, and the engineering org's ability to execute the plan the sponsor is underwriting.

It is not an IT audit. It is not a security scan. It is a senior engineering opinion on whether the technology can deliver the returns the model assumes, and what it will cost to get there.

Tech due diligence for M&A and private equity

PE and M&A teams have a different problem than a CIO doing an internal review. The clock is short, the target's team is guarded, and the questions are commercial before they are technical.

A sponsor underwriting a buy and build does not need a 200 page report on framework versions. They need to know whether the platform can absorb three bolt on acquisitions without a rewrite. A growth investor backing a SaaS due diligence exercise needs to know if the multi tenant architecture supports the ARR trajectory in the model, or whether the next 40% of revenue triggers a re platforming.

The thesis is the scope

The deal thesis dictates what technology due diligence actually looks at. Cost takeout deals need infrastructure and headcount analysis. International expansion deals need data residency and latency work. AI product deals need model provenance, training data rights, and inference cost curves. A generic technical due diligence checklist misses all of this.

Software due diligence vs SaaS due diligence

The terms get used interchangeably, but they are not the same job.

Software due diligence covers any target that ships code: on premise vendors, embedded systems, professional services firms with proprietary IP. The core questions are ownership, licensing exposure, and buildability without key people.

SaaS due diligence is narrower and denser. Multi tenancy design, unit economics per tenant, cloud spend as a percentage of revenue, uptime history, and customer facing SLAs. The financial model lives inside the architecture.

A good Technical Due Diligence engagement scopes the work to whichever of these two the target actually is, and does not pretend one framework covers both.

The technical due diligence process

A senior led process runs in three compressed phases, usually across two to four weeks depending on deal timing.

Phase one, thesis alignment. Sit with the deal team, read the CIM, understand what the model assumes about technology. Turn those assumptions into testable questions.

Phase two, evidence gathering. Code review of representative repos, architecture walkthroughs with the CTO, interviews with two or three senior engineers, review of incident history, security posture, and cloud bills. Not a survey. Actual reading of actual code.

Phase three, thesis test. Write findings against the thesis, not against a generic maturity model. If the thesis assumes AI leverage, the report answers whether the team can actually build and operate AI features, referencing the kind of embedded AI and Data work that separates a prototype from production.

Technical due diligence checklist

A thesis aligned checklist is short and pointed:

• Architecture fit for the next 3x of scale in the model
• Code ownership, open source licensing, and IP chain of title
• Engineering org depth beyond the founder or lead architect
• Security posture proportionate to customer segment and regulation
• Cloud and infrastructure cost curve against revenue plan
• AI and data exposure, both risk and untapped leverage
• Delivery track record over the last 12 months, not slideware
• Known technical debt with a rough remediation cost range

Eight items, each answered with evidence. Anything longer becomes a compliance exercise.

Bridging the gap from due diligence to post acquisition integration

This is where most technical due diligence services fail their clients. The diligence team writes the report, invoices, and leaves. Ninety days later the sponsor needs someone to actually execute the remediation plan, and now a new team has to relearn the codebase from scratch.

That handoff gap is expensive. It shows up as delayed 100 day plans, missed integration milestones, and a portfolio company CTO who spends the first quarter re explaining problems that were already documented.

The better model keeps the diligence team available for post acquisition integration. The engineers who read the code during diligence are the same ones who help the portfolio company execute against the findings. No relearning, no political reset, no lost context.

Devspace runs technical due diligence with this specifically in mind: the same senior engineers who assess the target can stay embedded post close, either to lead remediation or to add engineering capacity while the portfolio company hires. It is one of the reasons 60% of Devspace assignments extend past the original scope.

Technical due diligence services and consulting

What to look for when selecting technology due diligence consulting:

1. Senior only staffing. Partners or principals reading the code, not associates running a template. Junior led diligence produces junior insights.
2. Thesis first scoping. The engagement letter references the deal thesis, not a generic scope of work.
3. Post close continuity. The same team is available for post acquisition integration or capacity, on time and materials, without a new commercial process.
4. European coverage for European deals. Timezone and language alignment matter more than most sponsors expect during a fast moving process.

Those four filters cut the field of technical due diligence consulting firms sharply.

IT due diligence in M&A transactions

IT due diligence, narrowly defined, covers the corporate IT stack: identity, endpoints, licensing, and enterprise systems. In an M&A transaction it sits alongside technical due diligence but rarely overlaps. Confusing the two produces reports that miss the software risk entirely.

For a software company target, IT due diligence is a footnote. The product engineering org is the asset. For a services company or a traditional operator being digitised, IT due diligence carries more weight and technical due diligence is scoped to any proprietary systems.

Know which one the deal actually needs before scoping either.

The takeaway

Atlassian's 2025 repricing is not a one off. AI is revaluing software companies inside single reporting periods, and the technical questions have moved from "is the code clean" to "can this team survive the next architectural shift." Deal teams that still buy generic checklist diligence will keep finding out post close what a senior engineer could have told them in week two.

Tie the scope to the thesis. Staff it senior. Keep the team available for what comes after signing.