Technology Due Diligence: What a Skipped Audit Costs

Every acquisition I’ve watched go sideways after closing had the same shape: the financial model was airtight, the legal review was thorough, and nobody with engineering judgment ever looked at the actual system before the wire transfer went out. The buyer checked revenue, checked contracts, checked cap tables. Nobody checked whether the software could survive contact with a second team. That gap has a name: skipped technology due diligence.

That’s not a legal gap. That’s not a financial gap. That’s a technology due diligence gap, and it’s the one buyers consistently underprice because it doesn’t show up in a data room the way a balance sheet does.

At Iterators, we’ve worked on both sides of this. We’ve been the team called in to stabilize something after the deal closed, and we’ve been the team running the audit before the deal closes. The difference in outcome between those two engagements is not subtle. One is a controlled, priced risk. The other is an emergency with a legal team attached.

Here’s what technology due diligence actually is, why skipping it is a specific and measurable financial decision, and what to check before you sign, not after.

What Technology Due Diligence Actually Checks

Legal due diligence tells you whether the entity is real, whether the contracts are enforceable, and whether the founders own what they say they own. Financial due diligence tells you whether the revenue is real and whether the margins hold up. Neither of those tells you whether the software works, whether it can scale, or whether the two engineers who understand it are staying.

Technology due diligence is the technical review of a software company’s codebase, infrastructure, security posture, data systems, and development team before the acquisition closes. It answers a different question than legal or financial diligence: not “is this business legitimate,” but “can this system survive being owned by someone new.”

A product demo answers neither question. A demo shows you the happy path, on the seller’s laptop, on their good day. It tells you nothing about deployment, nothing about test coverage, nothing about what happens when the founding engineer who wrote the billing logic takes a job somewhere else three weeks after close.

I’ve seen buyers treat a clean demo as evidence of technical health. It isn’t evidence of anything except that someone can click through a UI in the right order.

The technical debt research from CISQ puts a number on what buyers are actually walking into. Their most recent estimate put the cost of poor software quality in the US at $2.41 trillion in 2022, with $1.52 trillion of that sitting as accumulated technical debt: code and architecture decisions that will cost more to fix later than they would have cost to do right the first time. That debt doesn’t show up on a balance sheet. It shows up in your engineering team’s velocity six months after you own the thing. Skipping technology due diligence doesn’t make that debt disappear — it just decides who discovers it, and how expensive the discovery turns out to be.

Where the Money Goes When You Skip Technology Due Diligence

I want to walk through a composite scenario, not because it’s dramatic, but because the individual line items are each things I’ve watched happen separately, and the arithmetic is worse when they stack.

A private equity-backed buyer acquires a niche SaaS company. ARR looks solid. Customer logos are recognizable. The demo is clean. To keep the deal timeline tight, the buyer skips the deep technical audit and relies on financial and legal review alone.

Ninety days after close, four things surface in sequence. The infrastructure was hand-configured by one engineer and was never captured in code. There were no Terraform or CloudFormation files defining the cloud infrastructure in version-controlled configuration, only a person who remembered how it was wired. The CI/CD pipeline, which automates software builds and deployments, only works from that engineer’s laptop because nobody ever documented the environment variables it depends on. An enterprise prospect asks for a SOC 2 report, an audit report covering how security controls operate over time, as a condition of signing. The platform has no audit logging and no role-based access control to produce one. Then the engineer who understands all of this leaves because the acquisition changed the culture he joined for.

None of these four things individually kills a deal. Together, they turn the first year of ownership into a remediation project instead of a growth project.

Here’s roughly what that remediation costs, based on the kind of engagement scope I’ve quoted for exactly this kind of cleanup:

Even at the low end of every range, that adds up to $1.4 million before you’ve shipped a single new feature the acquisition was supposed to justify. That’s the real price tag of skipping technology due diligence, not a worst-case scare number — it’s the low end of what I’ve seen quoted for exactly this kind of post-close cleanup, on deals in the tens of millions, not hundreds.

The security line item deserves its own weight, separate from the table. IBM’s 2025 data breach report puts the global average cost of a breach at $4.44 million, with US breaches averaging $10.22 million. The number that should actually worry an acquirer is the timeline: the average breach takes 241 days to identify and contain, with 181 days to find it and 60 more to contain it. If a breach happened under the seller’s ownership and surfaces on your watch eight months after close, you don’t get to point backward. You own it, you disclose it, and if you’re a public company or acquired by one, you’re on a four-business-day clock under the SEC’s Item 1.05 disclosure rule the moment you determine it’s material.

Nobody prices that risk into a term sheet unless someone specifically went looking for it before the deal closed.

What We Actually Look At in a Technology Due Diligence Audit

When we run a technical audit on an acquisition target, we're not producing a slide deck of recommendations. We're answering a specific, narrow set of questions, in this order:

1. Can a new engineer deploy this system using only the documentation, with no help from the current team? If the answer requires a Slack message to a specific person, that's your bus factor, and it's your biggest single risk.
2. Is the infrastructure defined in code, or is it defined in someone's memory? Hand-configured servers, manually provisioned databases, and undocumented DNS records are all the same problem wearing different clothes: nobody can reproduce production if it disappears.
3. What does the test suite actually cover, and does anyone trust it enough to deploy without manual verification? A codebase with no automated tests isn't necessarily broken. It's unmeasured. You're buying an unknown, and unknowns get priced at a discount or they get walked away from.
4. What's in the dependency tree, and are any of those licenses going to force you to open-source your own product? This is the one buyers skip most often because it feels like a lawyer's job. It isn't. A software bill of materials, a formal, complete inventory of every library and dependency in the codebase, is the only reliable way to know whether you've inherited a GPL or AGPL dependency buried three layers deep. These open-source licenses can create source-code disclosure obligations, depending on how the software is used and distributed.
5. Does the security posture survive contact with an actual enterprise procurement process? Not "do they have a firewall." Does the system have audit logging, role-based access control, encrypted data at rest and in transit, and evidence of a real incident response process? These are the specific controls a SOC 2 Type II report evaluates over a defined period.
6. What's the actual cloud spend, and is it sized to the business or sized to habit? I've seen platforms running production workloads on infrastructure that was right for the traffic two years ago and has never been revisited since. That's not a technical debt problem. That's a P&L problem hiding inside a technical decision.
7. Who actually knows how this system works, and are they staying? This is the question buyers ask last, if at all, and it should be near the top. A platform with mediocre code and a team that understands every corner of it is a manageable acquisition. A platform with clean code and zero institutional memory left after close is a bigger risk than either.

Every one of those questions has a concrete artifact you can request as evidence. Ask for the deployment runbook. Ask for the Terraform repository containing the infrastructure configuration. Ask for the last penetration test. Ask for the SBOM. If any of those don't exist, that's not automatically a deal-killer, but it's a cost you now need to price into the offer because someone has to build them after close if they don't exist before.

We say this internally, and it applies past acquisitions into every handoff situation we've been part of: deals founder when companies sign term sheets without mapping how IP, runbooks, support tickets, and key personnel actually transition. You need a rigorous hand-off audit, or you inherit undocumented processes and watch the integration stall for months while someone reverse-engineers what the seller's team already knew.

Reading the Findings: What Changes the Deal

An audit is only useful if it changes a decision. Findings sort into three tiers, and the tier determines what you do with them. Whether the code is "good" or "bad" is a meaningless binary for this purpose. This is really where technology due diligence earns its keep: not as a pass or fail grade, but as a plan for what to do next.

Yellow: proceed, but price it in. Low test coverage on an otherwise coherent architecture. Dependencies that are a version or two behind but not abandoned. Documentation that's uneven but exists. Manual deployment steps that are annoying but reproducible. These are normal technical debt. You don't walk away from a deal over this. You model the cleanup cost into year-one budget and move on.

Orange: renegotiate or hold back funds. No disaster recovery plan of any kind. Unclear ownership of the actual intellectual property, especially if contractors touched the code without assignment agreements. Security controls that will visibly fail the first enterprise vendor review. A single person holding all the operational knowledge with no succession plan. Customer commitments the current architecture can't actually support at the volume being promised. Any of these should move the number on the term sheet or trigger an escrow holdback tied to remediation milestones.

Red: pause the deal. Builds that can't be reproduced from source. In that situation, nobody, including the seller, can guarantee that what's running in production matches what's in the repository. A security incident history that wasn't disclosed. License violations serious enough to threaten your right to keep the code proprietary. Unclear or contested data rights over the customer data you think you're acquiring. An architecture that mathematically cannot scale to the volume the business plan assumes, no matter how much money you throw at it. These don't get priced in. They get fixed before signing, or the deal doesn't happen.

The mistake I see most often isn't buyers ignoring red flags outright. It's buyers treating orange flags like yellow ones because the deal has momentum and nobody wants to be the person who slows it down two weeks before close.

How the Technology Due Diligence Process Should Run

Technical due diligence doesn't need to be slow to be thorough. It needs to be sequenced correctly, and it needs someone with actual engineering judgment doing the looking, not a generalist consultant running through a checklist they don't fully understand.

The way we structure this work, whether it's for an acquisition or a straight technology takeover, breaks into four phases:

Landscape scan. Understand what the business actually depends on technically, before touching code. What are the systems that, if they went down for a day, would stop revenue. What's the strategic reason for the acquisition, and does that reason require this specific architecture to survive, or can parts of it be replaced without touching the business case.

Deep technical audit. Code review, architecture review, infrastructure review, security review, and actual conversations with the engineers who built the thing. This part gets skipped constantly. Documentation tells you what someone wrote down. A conversation tells you what they didn't bother writing down because it seemed obvious to them and won't be obvious to anyone else.

Sandbox deployment spike. This is the step most due diligence engagements skip entirely, and it's the one that catches what a demo can't. You stand up the actual system in an environment that mirrors your intended production load and integration requirements, and you watch what breaks. A demo shows you the system working on a good day with ten test users. A sandbox spike shows you whether it survives the traffic pattern you're actually planning to put on it.

Integration and remediation plan. A risk scorecard, a cost estimate for fixing what's broken, and a staffing plan for who does the fixing. This is the deliverable that actually changes the term sheet, rather than becoming a report that sits in a drawer after close.

None of this needs to take longer than a well-run legal due diligence process. It needs someone doing it who has actually shipped software under production load, not someone who's read about it.

What Happens After the Audit

Finding technical debt during due diligence doesn't automatically mean the answer is "rewrite everything." That's the instinct, and it's usually wrong. A full rewrite is expensive, slow, and introduces its own set of new bugs into a system you were trying to make more stable.

The better move, in most cases we've seen, is targeted: identify the specific pain points the audit surfaced, and address those in isolation rather than treating the whole platform as radioactive. If the billing engine is the fragile part, extract it. If the infrastructure is the fragile part, codify it without touching the application layer. This is the same logic behind the Strangler Fig pattern for legacy modernization: wrap the risky part, replace it gradually, and keep the rest of the system running while you do it. You can isolate and replace a fragile component without rewriting the rest of the system.

The decision comes down to what the technology due diligence findings actually show and how much runway you have. Maintain and stabilize if the core is sound and the problems are operational. Rewrite only the pieces that are structurally broken, not the whole product. Move toward microservices or a modular monolith if the business genuinely needs the scaling flexibility and can absorb the 15-25% engineering overhead that comes with running distributed systems instead of one deployable unit. What you don't do is decide the architecture strategy before you've read the audit. That's backward, and it's how buyers end up rewriting systems that didn't need rewriting, or limping along with systems that did.

My co-founder Jacek puts it plainly when clients ask which path to take: the single most expensive mistake is ignoring your own business context. No two modernization journeys are the same, but every decision starts at the intersection of roadmap, budget, and burn rate, not at the intersection of what sounds architecturally impressive.

The Part Buyers Underweight Most

If there's one finding from every post-close cleanup we've run that surprises buyers more than the code quality or the infrastructure gaps, it's the team dependency. Buyers model risk around the software as an artifact, treating the codebase as the asset and the people as incidental. In practice, the people who understand why the system was built the way it was are frequently more valuable than the code itself, and they're the part of the acquisition most likely to walk within the first six months if the transition is handled badly.

You can price bad code into a term sheet. You can escrow against a security gap. You can't escrow against an engineer deciding the acquiring culture isn't for them and taking the only working mental model of your billing system with him on his way out the door.

That's the risk no technology due diligence checklist fully captures, and it's the reason the audit needs to include actual conversations with the people who built the thing because their commit history is not enough.