The importance of software quality audits during M&A due diligence: Stories from the field

Should I worry about processes or architecture?

Our approach to assessing processes and architecture is holistic. We combine artifact reviews and interviews with engineering leadership and delivery teams alongside documents to build a full picture of how the product is developed, operated, and supported. The goal is not to audit process compliance or critique architecture in isolation, but to understand how all those pieces come together in practice.

That broader view regularly surfaces surprises that matter in an M&A context. In one Software Development Audit, what the acquirer had been led to believe was a largely in‑house engineering organization turned out to rely heavily on outsourced developers for core product work. That discovery did not automatically make the deal unattractive, but it did change the conversation. Heavy outsourcing raises very practical questions around intellectual property ownership, where critical product knowledge really lives, and how continuity will be maintained postclose. Uncovering this type of intelligence during due diligence allows buyers to plan and sometimes introduces reps and warranties to improve the deal for the acquirer. In some cases, it even impacts valuation. Finding it after close usually means absorbing risk no one priced in.

Digging into software architecture can yield similar stories. In one engagement, we uncovered a highly layered design necessitated by unreliable internet infrastructure in the company’s geographic home market. To keep the product usable, the team introduced multiple relay layers between customer environments and a central server. It was a clever solution to a real problem, but it also created fragile synchronization patterns and added operational complexity that an acquirer would inherit. The audit wasn’t about labeling the design as good or bad. It was about evaluating the tradeoffs, costs, and integration implications visible before they became the buyer’s responsibility. Too often, such revelations only surfaced months after the deal is done.

Should I worry about the code?

Even when processes look reasonable and documentation is thorough, the code itself often tells a different story. The Code Quality Audit and Design Quality Audit are about answering a straightforward question: How healthy is this code, and what will that mean going forward? We look at coding standards and structure to understand how maintainable, scalable, and secure the software will be over time.

Sometimes, the story is reassuring. We open a codebase and it is clean, consistent, and clearly written by teams that care about quality. In those cases, the audit does not introduce drama; it reinforces buyer confidence. We’ve had clients tell us that our assessment of the code validated what they were already being told about the target’s engineering maturity, and helped confirm that they were making the right acquisition decision. So even in transactions that would have led to smooth sailing, the buyers appreciated knowing the ship was on course.

Other times, the code reveals issues that process reviews alone would never surface. Even the most transparent sellers will put a positive spin when describing development processes. The rubber meets the road in the code. For example, a product that a target described broadly as “.NET” turned out to include large amounts of VB.NET (older, legacy technology), which really complicated the acquirer’s modernization plans.

Common issues we uncover through comprehensive, deep code analysis are weak code revision management, large numbers of basic issues that should have been caught earlier, exposed credentials, and critical business logic buried deep in stored procedures across multiple database dialects. When maintainability and security risks like these start stacking up software quality quickly stops being an academic concern. It becomes a direct input into valuation discussions, integration planning, and postclose priorities. Just talking through development processes and reviewing a handful of curated code samples is not enough.

What about the impacts of AI?

AI has added an entirely new dimension to software diligence. Increasingly, buyers need to focus on the product’s claims about the use of AI and as well as how that AI is implemented, governed, and improved over time. The gap between marketing narratives and technical reality is where some of the most important diligence insights tend to emerge.

In one engagement, an acquisition was attractive in part due to the product being an “AI solution.” Our audit uncovered a more nuanced picture. The product relied on a bring‑your‑own‑model approach, requiring its customers to supply their own large language model and credentials. The company itself did not operate a proprietary production model, and the design intentionally prevented training on customer data. That limited differentiation from any other similar solution utilizing AI, though it also reduced exposure around intellectual property leakage and misuse of client data. The takeaway wasn’t that the product lacked value, but the buyer’s expectations needed to be reset before deal assumptions hardened.

We are also frequently asked the opposite question: Can a product that doesn’t leverage AI survive disruption? Audits that look closely at data complexity, regulatory constraints, deeply embedded workflows, and the need for human oversight often show why the answer may be “yes.” Domain expertise, hard‑to‑replicate data access, and trust‑driven processes can create real defensibility.

Quality audits with an AI lens help separate genuine AI risk from noise and grounds the conversation in how the product actually delivers value today.