What Does a Technical Due Diligence Actually Reveal?

TL;DR / Key Takeaways

- Technical due diligence doesn't decide whether to buy a company. It tells you exactly what you're buying and what it will cost to fix.

- The biggest risks hide in untested code, single-engineer dependencies, outdated libraries, and inconsistent architecture.

- According to McKinsey, 70% of M&A deals fail to capture expected value, and undetected technical debt is a leading cause in tech acquisitions.

- A structured code audit shifts the conversation from "should we buy?" to "what's our 90-day engineering plan post-close?"

Last year, a private equity firm asked me to review the codebase of a mobile banking startup they were about to acquire. The deal was in the tens of millions. The app had solid download numbers, growing revenue, and a founding team that interviewed well. Everything on the surface looked right.

I spent four days inside the codebase. On the second day, I found a file called `AuthManager.swift` that was 3,400 lines long. It handled login, session management, token refresh, biometric authentication, and, inexplicably, parts of the payment flow. There were no tests for it. One engineer had written most of it, and that engineer had left the company eight months earlier.

That single file didn't kill the deal. But the conversation it started changed the deal's terms by a significant margin. And that's what technical due diligence actually does. It doesn't decide whether to buy. It decides what you're really buying.

Why Does "It Works" Not Mean "It's Built to Last"?

Every app I've audited works. If it didn't, there would be no users, no revenue, and no deal to evaluate. The real question is whether the code can survive what comes next.

Can the codebase handle three times the current user load? Can a new engineer onboard and ship a feature within two weeks? Can the team migrate to the next major iOS version without a rewrite? Can the architecture absorb a pivot in product direction without collapsing?

According to Stripe's Developer Coefficient report, developers spend an average of 33% of their time dealing with technical debt and maintenance. For an acquirer, that means one-third of your new engineering team's capacity may already be consumed before they write a single line of new code.

I've reviewed codebases where the UI was polished, the animations were smooth, and the App Store rating was 4.7, but underneath, the data layer was a tangle of singletons passing mutable state through notification observers. The app worked beautifully on the day I reviewed it. But adding any meaningful new feature would have been like performing surgery on a house of cards.

What Red Flags Actually Change Deal Terms?

Over the years, I've developed a checklist of things that matter most. None of them are glamorous. All of them are predictive.

Bus Factor

This is the number of engineers who would need to leave before critical knowledge disappears. In the banking startup I mentioned, the bus factor for the authentication system was zero. The only person who understood it was already gone.

A 2023 survey by Codesee found that 65% of engineering teams have at least one critical system understood by a single developer. When I see modules where one person made 90% of the commits and left no documentation, that's not just a technical risk. It's a business risk that needs to be priced into the deal.

Test Coverage Theater

I've seen codebases that report 80% test coverage. Impressive, until you look at what's actually being tested.

According to Martin Fowler's testing guidelines, the most valuable tests target the behavior that matters most to users and the business. A codebase with 40% meaningful coverage is healthier than one with 85% performative coverage.

Dependency Rot

Every iOS project has dependencies. The question is whether anyone is managing them. A Synopsys Open Source Security and Risk Analysis (OSSRA) report found that 91% of commercial codebases contain open source dependencies that are more than four years out of date.

I once audited an app that depended on a networking library whose last commit was three years old and whose maintainer had publicly archived the repository. The app also used a payment SDK two major versions behind, meaning it was missing critical security patches. Dependencies are promises made by strangers. If nobody on your team is tracking whether those promises are still being kept, the codebase is accumulating risk invisibly.

Security Gaps

In regulated apps, especially in fintech, security isn't optional. Common issues I find during audits:

According to IBM's Cost of a Data Breach Report 2024, the average cost of a data breach in financial services reached $6.08 million. For a pre-acquisition target, a single security gap can wipe out projected deal value. Apple's own security documentation sets clear expectations for iOS apps handling sensitive data, and failing to meet them is a red flag for any acquirer.

Architecture Coherence

This is the hardest thing to quantify but often the most telling. Does the codebase have a consistent architecture, or does every module follow a different pattern depending on who wrote it and when?

I've seen apps where the first screens were built with MVC, the middle section used MVVM, and the newest features were attempting VIPER. Each pattern was implemented partially. None were implemented well. This kind of architectural drift tells me the team never had, or stopped maintaining, a shared understanding of how the app should be built. A 2024 JetBrains Developer Ecosystem survey found that inconsistent architecture is cited by 42% of developers as the primary barrier to onboarding new team members.

How Does a Due Diligence Report Change the Deal?

The report doesn't say "don't buy this company." It says "here's what you're actually acquiring, and here's what it will cost to get it where it needs to be."

Sometimes the report reveals that the codebase is stronger than expected. I reviewed a health-tech app once where the architecture was so clean and well-documented that I told the acquirer it was one of the best codebases I'd seen in a company of that size. That finding increased their confidence and actually accelerated the timeline.

More often, the report identifies specific areas of technical debt that need to be addressed post-acquisition. According to Bain & Company research, acquirers who conduct thorough technical assessments are 2.5 times more likely to achieve target deal synergies within the first two years.

In the banking startup deal, my report identified:

The acquirer used that information to negotiate different terms and budget for six months of focused iOS engineering work post-close. Without the technical due diligence, they would have walked in assuming the codebase was as healthy as the revenue numbers suggested.

What Happens on the Human Side of a Code Audit?

Behind every line of code is an engineer who wrote it under specific constraints, with specific knowledge, under specific pressure. The 3,400-line `AuthManager` wasn't written by a bad engineer. It was written by someone who was probably the only iOS developer at a startup that was moving fast, who didn't have time to refactor, who was solving urgent problems with the tools and context available.

I write my reports without judgment of the individuals. The goal isn't to grade the engineering team's work. It's to give the acquirer an honest picture of where the codebase stands and what it will take to move it forward.

The best outcome is when the existing engineering team reads the report and says, "Yes, we know about these issues, and here's what we would do about them with the right resources." That alignment between the report and the team's own awareness is one of the strongest signals I can give an acquirer. A team that knows its weaknesses is a team that can fix them.

What Separates Codebases That Pass From Those That Fail?

People ask me this question directly: did the codebase pass or fail? I resist the framing, because it implies a binary that doesn't exist. But if I had to distill what separates codebases that give acquirers confidence from those that give them pause, it comes down to three things.

No codebase is perfect. The ones that pass due diligence aren't flawless. They're honest, consistent, and built by teams who understood that the code would eventually need to outlast them.

How Should You Prepare for a Technical Due Diligence?

Whether you're the acquirer commissioning a review or the target company being evaluated, preparation matters. Here's what I recommend:

For acquirers:

For target companies:

The most successful acquisitions I've been part of are the ones where both sides treated the due diligence as a shared planning exercise, not an adversarial exam.

FAQ

How long does a technical due diligence take?

Most mobile app due diligence reviews take three to five business days for a single-platform codebase. Complex multi-platform apps or codebases with microservice backends can take one to two weeks. The timeline depends on codebase size, the number of platforms, and the depth of review requested by the acquirer.

What is the difference between technical due diligence and a code audit?

A code audit focuses narrowly on code quality, patterns, and defects. Technical due diligence is broader. It evaluates architecture, team risk, dependency health, security posture, scalability, and how the codebase maps to business objectives. It answers the question: can this technology support the acquirer's growth plans?

How much does unresolved technical debt typically cost post-acquisition?

Industry research varies, but McKinsey estimates that technical debt costs companies 10-20% of their annual technology budgets. For acquisitions specifically, unplanned remediation can add 15-30% to projected post-deal engineering costs if the debt wasn't identified during due diligence.

Should the target company's engineering team be involved in the review?

Yes. The best outcomes happen when the existing team participates. Their context about why certain decisions were made is invaluable, and their reaction to findings tells the acquirer a lot about the team's self-awareness and capability. Adversarial reviews that exclude the engineering team miss critical context.

What programming languages and platforms does Luma Commons review?

Our core expertise is in iOS and Swift, which is where most of our due diligence engagements focus. We also review cross-platform codebases built with React Native and Flutter, and evaluate backend architectures when they directly impact the mobile product. For a full picture of our capabilities, visit Luma Commons.