Technical Due Diligence: What Acquirers and Investors Actually Look For in a SaaS Codebase

If your SaaS company is heading toward an acquisition, a private equity investment, or even a Series A round, someone is going to read your code. Not skim it. Read it. A technical due diligence checklist used to be a formality that lawyers ticked off between the term sheet and the wire transfer. That era is over. Today, private equity firms, strategic acquirers, and increasingly early-stage investors commission serious technical reviews, and the findings routinely claw back valuation, restructure earn-outs, or kill deals outright.

This post is written from the seller's side of the table. Not "how to conduct due diligence" but "how to survive it" - and ideally, how to walk into the data room knowing exactly what the reviewers will find, because you found it first.

Why Technical Due Diligence Became a Deal-Blocker

Two things changed. First, software is now the asset in most SaaS acquisitions. The buyer is not acquiring your customer list or your brand; they are acquiring a codebase they intend to operate, extend, and integrate for years. A codebase that needs a rewrite is not an asset, it is a liability with a subscription business attached.

Second, buyers got burned. Every mid-size PE firm has a story about the portfolio company whose "modern platform" turned out to be an unmaintainable tangle that consumed two years of engineering budget post-close. Those stories produced process: standardized review frameworks, specialist due diligence firms, and deal terms that shift technical risk back onto the seller through escrows, holdbacks, and price adjustments.

The practical consequence for you: technical findings now have a price tag. A weak security posture or a single irreplaceable engineer does not just make the buyer nervous. It shows up as a number in the revised offer.

The Technical Due Diligence Checklist: Five Areas Reviewers Consistently Flag

Having sat on both sides of these reviews through code quality consulting engagements, I can tell you the findings cluster. Reviewers at the established due diligence firms work from similar frameworks, and the same five areas produce the majority of red flags.

1. Architecture Debt

Reviewers are not looking for a fashionable architecture. They are looking for whether the architecture can absorb the buyer's growth plan. The questions behind the questions:

• Can this system scale to 5x the current load without a rewrite?
• How coupled are the modules? Can a new team ship a feature without understanding the whole system?
• Are there components everyone is afraid to touch?

What a finding looks like in practice: a "microservices architecture" that is actually a distributed monolith where every service reads the same database tables. Or a core billing module last meaningfully modified four years ago, wrapped in layers of workarounds because nobody dares change it. Reviewers find these quickly because they interview engineers and ask "what part of the system would you be most nervous to change?" Engineers answer honestly. They always do.

2. Security Posture

This is the area most likely to produce a deal-threatening finding, because security problems create legal exposure the buyer inherits. Reviewers check:

• Authentication and authorization patterns, especially tenant isolation in multi-tenant systems
• Secrets management: credentials in the repository history are a classic and depressingly common finding
• Dependency vulnerabilities with known CVEs sitting unpatched
• Whether there has ever been a penetration test, and what happened to its findings

The findings that hurt are rarely exotic. They are things like an admin endpoint protected only by URL obscurity, API keys committed in 2021 and never rotated, or cross-tenant data access possible by editing an ID in a request. Any one of these can trigger a holdback until remediation is verified.

3. Test Coverage Quality

Note the word quality. Reviewers stopped trusting coverage percentages years ago, and the rise of AI-generated test suites has made raw coverage numbers close to meaningless. A codebase can show 85% line coverage where half the tests assert nothing beyond "the function did not throw."

What reviewers actually do: they read a sample of tests for the business-critical paths - billing, permissions, data export - and check whether the assertions would catch a real regression. They look at whether tests run in CI on every change, how long the suite takes, and how often it is skipped. They may ask an engineer to break something on purpose and see if the suite notices.

A finding here rarely kills a deal on its own, but it amplifies every other finding. Weak tests mean the buyer cannot safely change the code they are buying, which turns every planned integration into a risk line item.

4. Dependency Risk

Every external dependency is a small contract with a stranger, and reviewers audit those contracts:

• Frameworks and runtimes past end-of-life (an EOL PHP or Node version is an automatic finding)
• Critical libraries that are abandoned or maintained by one person
• License compliance: a GPL dependency in a proprietary SaaS product is a legal finding, not a technical one, and lawyers get involved
• Third-party services the product cannot function without, and what the contracts around them look like

Legacy platform versions deserve special mention because they compound. Being three major versions behind on your framework means security patches are unavailable, hiring is harder, and every modernization estimate the buyer makes gets padded. If this is your situation, a structured legacy code modernization effort before you go to market is one of the highest-ROI moves available.

5. Team Bus Factor

The most underestimated area, and the one founders can least fix in a hurry. Reviewers ask: if one specific person left the company the day after closing, could the remaining team operate and extend the system? In far too many SaaS companies the honest answer is no. One engineer holds the deployment process, the tribal knowledge about the billing edge cases, and the only real understanding of the core domain model - all in their head.

Reviewers detect this through interviews and through the commit history, which does not lie. If 70% of commits to the core system come from one person, that person is a single point of failure, and the buyer will price the risk of losing them. Documentation, onboarding runbooks, and deliberate knowledge-spreading in the months before a deal measurably change this finding.

Score Your Codebase Before a Buyer Does

The single most valuable thing you can do before a process starts is an honest internal assessment against the same criteria. Not a pep talk. A scored review with evidence, the kind of exercise we describe in our codebase health scorecard approach.

For each of the five areas, ask three questions:

1. What would a skeptical external reviewer find in the first two days?
2. What would engineers say in interviews when asked what worries them?
3. What evidence exists to counter the concern - tests, docs, monitoring, audit trails?

Score each area red, amber, or green, and be brutal about it. A self-assessment that comes back all green is a self-assessment that was not honest. Every real codebase carries debt; buyers know this, and reviewers get suspicious when a seller claims otherwise. The goal is not perfection. The goal is that nothing in the eventual report surprises you.

If you want an external calibration, a focused pre-diligence audit by a third party is dramatically cheaper than the valuation haircut from an unexpected finding. It also produces something valuable: a written record that issues were identified and remediation was underway before the buyer showed up.

The Remediation Timeline Buyers Find Credible

How you talk about fixing known issues matters as much as the issues themselves. Buyers have well-tuned detectors for two failure modes.

The first is the miracle timeline. "We will migrate off the EOL framework in six weeks" reads as either dishonesty or naivety, and both damage trust in everything else you have said. Framework migrations, tenant isolation retrofits, and test suite rebuilds are quarter-scale efforts, and experienced reviewers know the real numbers.

The second is the eternal backlog. Issues that have been "on the roadmap" for two years without a single commit against them are not planned work, they are accepted decay. A backlog ticket is not remediation.

What lands well is specific and already moving: a written plan per finding, an owner, a realistic quarter-level timeline, and evidence that work has started - merged pull requests, a migration guide, a completed proof of concept. "We identified this in our internal review in Q1, here is the plan, here are the first three merged changes" is the strongest sentence a seller can say in a due diligence interview.

Present Known Issues Proactively

Founders' instinct is to hope reviewers miss things. They will not. A competent team with two weeks and data room access finds essentially everything material. What you control is whether each issue arrives framed by you or discovered by them.

Disclosed issues read as engineering maturity. Discovered issues read as either ignorance or concealment, and both are worse than the issue itself. The practical move is a short "known technical debt" document in the data room: each material issue, its business impact, and its remediation status. This document does more for buyer confidence than any amount of polish, because it signals that the team sees its own system clearly. It also connects to how you talk about debt internally - if you can already communicate technical debt to non-technical stakeholders, you can write this document in an afternoon.

A Self-Assessment Checklist to Run This Quarter

Condensed to the checks that map to what EU-market due diligence firms actually score:

• Architecture: Can you draw the system on a whiteboard in ten minutes? Do module boundaries match team boundaries? Is there a component nobody will touch?
• Security: Secrets out of the repo and rotated? Tenant isolation tested, not assumed? Dependency scanning in CI? A pen test in the last 18 months with findings closed?
• Tests: Do tests on billing and permissions assert real behavior? Does CI block merges on failure? Would a deliberately introduced bug be caught?
• Dependencies: All runtimes and frameworks inside support windows? License inventory checked against your commercial model? No critical single-maintainer libraries without a fallback plan?
• Team: Could every critical system survive one specific resignation? Do runbooks exist and match reality? Is knowledge of the core domain spread across at least two people?

Anything you cannot answer confidently is what a reviewer will find. Better to know now, while it is a work item rather than a negotiation item.

Get Ahead of the Review

Technical due diligence rewards preparation more than almost any other part of a deal process. The findings are predictable, the frameworks are consistent, and nearly every valuation-damaging discovery could have been found and fixed - or at least honestly disclosed - months earlier.

If a transaction is on your horizon, run the self-assessment above this quarter. And if you want an external, evidence-based review before a buyer commissions theirs, that is exactly the work we do at Wolf-Tech: independent codebase audits calibrated to what acquirers and investors actually check. Reach out at hello@wolf-tech.io or visit wolf-tech.io to talk it through.