Software Due Diligence: Code, Security and Scalability

Software due diligence is the part of a deal where someone gets to look under the hood of the product and ask one blunt question: is this code actually worth what we are paying for it? I have sat on both sides of that review. I have handed over a repository to a buyer's engineers during an acquisition, and I have read another team's commit history at midnight trying to decide whether their "scalable platform" was real or a slide. The gap between the pitch deck and the source tree is where deals get repriced, and software due diligence is how you find that gap before money moves.

This guide covers what software due diligence examines, who runs it and when, a step-by-step process, a checklist you can hand to your team, the red flags that show up most often, and how a data room keeps the whole thing from turning into a mess of zip files and email threads. For the wider context, start with the due diligence pillar, which maps how all the diligence workstreams fit together.

What software due diligence is

Software due diligence is a focused assessment of a target company's code, security posture, and ability to scale. It asks whether the software that the business sells (or runs on) is well built, legally clean, secure enough to operate, and capable of handling growth without a rewrite.

It is a narrower cut than technical due diligence. Technical diligence covers the whole engineering function: infrastructure, the team, DevOps maturity, hiring risk, and the roadmap. Software due diligence zooms in on the artifact itself, the actual codebase and the systems built around it. The two overlap, and on a small deal one reviewer does both. But when a buyer says "we need a software audit," they usually mean three things: the quality of the code, the security of the application, and whether the architecture will hold up.

Three pillars sit at the center of every review I have run:

• Code. Quality, structure, maintainability, test coverage, technical debt, and the open-source licenses baked into the build.
• Security. Known vulnerabilities, how secrets and customer data are handled, access controls, and whether the team has ever had a breach they did not disclose.
• Scalability. Whether the architecture can take 10x the load, what the single points of failure are, and how much it would cost to grow.

Who runs it and when

On the buy side, software due diligence is run by the acquirer's engineering leadership, sometimes a specialist diligence firm, or a technical partner at the investing fund. Founders running a Series A are increasingly asked to submit to a lighter version of it by their lead investor's technical advisor. On the sell side, smart founders run their own version first so they are not surprised by what the buyer finds.

The timing usually breaks down like this:

• Fundraising (Series A and later). A technical advisor reviews the codebase to confirm the product is real and the team can ship. Lighter touch, but it happens.
• Acquisition. This is the heaviest version. The buyer wants to know what they are inheriting, including liabilities, before they sign. This sits inside the larger m&a due diligence effort alongside financial and legal review.
• Private equity investment. A PE firm taking a majority stake wants to confirm the platform can support the growth plan they are underwriting.
• Pre-sale (sell side). The founder or their advisor audits the code to fix the obvious problems before a buyer ever sees them. The cheapest finding is the one you fix yourself.

The point is the same in every case: reduce the chance of a nasty surprise after the papers are signed.

The software due diligence process, step by step

Here is the sequence I use. It scales down for a small SaaS deal and up for a platform acquisition, but the order holds.

1. Scope and request. Define what is in and out. Are you reviewing one product or a whole portfolio? Agree on access: read-only repository access, a code-scanning report, or a supervised walkthrough. Then send a structured request list. A due diligence data room checklist is a good starting template even though it is broader than software alone.

2. Codebase review. Read the code, or run automated tooling across it, or both. You are looking at structure, naming, test coverage, commit history, and how concentrated the knowledge is. A repository where one person wrote ninety percent of the commits is a risk regardless of how clean the code looks.

3. Open-source and license scan. Run a software composition analysis tool to inventory every third-party dependency and its license. This is where a lot of hidden liability lives. A copyleft license like GPL in a proprietary product can force disclosure of source code, and buyers will not ignore it.

4. Security assessment. Review for known vulnerabilities, check how secrets are stored, look at authentication and authorization, and ask for the results of any past penetration tests. If the company holds a security certification like SOC 2 or ISO 27001, confirm it is current. Certification evidence belongs in the room from day one, and choosing the best data room for due diligence makes it easy to expose that evidence without exposing everything else.

5. Architecture and scalability review. Get a system diagram, then test it against the growth plan. Where are the bottlenecks? What is the database strategy at 10x users? What breaks first? This is where you find out whether "cloud native" means anything.

6. Team and process check. How does code get from a laptop to production? Is there code review, CI, automated testing, monitoring? A strong process partly compensates for messy code, because it means the team can fix things. The absence of any process is its own red flag.

7. Findings and report. Severity-rank every issue, separate "must fix before close" from "fix in year one," and translate the findings into deal language: this is a remediation cost, this is a valuation adjustment, this is a walk-away. The output feeds the broader due diligence report the deal team relies on.

Software due diligence checklist

This is the working checklist I hand to a review team. It is organized by the three pillars plus the process layer.

Area	What to verify	Why it matters
Code quality	Structure, readability, test coverage, technical debt	Predicts cost and speed of future work
Commit history	Activity, contributor spread, recent velocity	Reveals bus-factor and whether the team still ships
Open-source licenses	Full dependency inventory, license types, copyleft exposure	Hidden legal liability that can force code disclosure
Known vulnerabilities	Dependency CVEs, unpatched libraries, scan results	Direct breach risk the buyer inherits
Secrets and data	How keys and customer data are stored and encrypted	Compliance exposure and breach blast radius
Access controls	Authentication, authorization, least privilege	Insider and account-takeover risk
Security history	Past breaches, disclosures, penetration test reports	What has already gone wrong, and was it handled
Certifications	SOC 2, ISO 27001, status and scope	Customer trust and enterprise sales readiness
Architecture	System diagram, single points of failure	Where the product breaks under load
Scalability	Database strategy, load handling, growth cost	Whether the platform supports the plan
Infrastructure	Hosting, cost structure, disaster recovery, backups	Operating risk and surprise bills
Engineering process	Code review, CI/CD, testing, monitoring, on-call	Whether the team can fix what diligence finds
IP ownership	All code written by employees or assigned contractors	That the company actually owns what it is selling

The IP ownership line at the bottom is small but it has killed deals. Code written by a contractor who never signed an assignment agreement does not belong to the company, and a buyer will treat that as a defect in the asset.

Common red flags

After enough reviews you start to recognize the warning signs early. These are the ones I watch for.

A single contributor wrote everything. Concentrated knowledge means concentrated risk. If that person leaves, the codebase becomes unmaintainable and the buyer knows it.

No tests, or tests that do not run. A test suite is a proxy for engineering discipline. Its absence usually means changes are scary, which means the product is slow to evolve.

Copyleft licenses in a proprietary product. GPL or AGPL code inside a closed-source product is a legal problem, not a style preference. It can force source disclosure or require a rewrite.

Hardcoded secrets in the repository. API keys and passwords committed to source control signal weak security hygiene and often mean those secrets are already exposed in the commit history.

An undisclosed breach. If you find evidence of a security incident that was never mentioned, the issue is no longer just the breach. It is what else the team chose not to tell you.

A monolith presented as a scalable platform. Sometimes fine, sometimes a wall. The red flag is the mismatch between the architecture and the growth story being sold.

Stale dependencies. A build full of years-old libraries with known vulnerabilities tells you maintenance has not been a priority, and the catch-up cost lands on the buyer.

None of these automatically kills a deal. Most become a price negotiation or a remediation plan. The danger is finding them after close.

How a data room streamlines software due diligence

Software due diligence runs on documents and access, and that is exactly where a virtual data room earns its keep. I have watched a review slow to a crawl because the architecture diagrams, security reports, and license inventory were scattered across email, Slack, and a shared drive nobody could navigate. A data room fixes that by giving every reviewer one organized, permissioned, auditable place to work. The broader case is in the guide on virtual data room due diligence, but a few things matter specifically for a software review.

Granular permissions. Source code and security reports are the most sensitive documents in any deal. You want to control who sees what down to the individual file, and revoke it the moment a party drops out. Getting that wrong is how confidential material leaks.

Audit trail. A complete log of who opened which document and when protects both sides. The buyer proves they did the work, and the seller knows exactly what was reviewed.

Structure that signals competence. A well-organized room sends a message before anyone reads a line of code. It tells the buyer this is a team that has its act together, and that impression carries into the negotiation.

This is the problem Plox is built for: a secure data room for founders, investors, and dealmakers who want file-level control, a clean audit trail, and a room they can stand up quickly without an enterprise procurement cycle. A software review involves the most sensitive material in the deal, which is the worst place to be casual about access. If you are weighing the spend, the breakdown of virtual data room cost covers how pricing models compare across providers.

A clean room will not make bad code good. But it makes a good review faster, a fair one easier, and a careless leak much less likely.

Frequently asked questions

How long does software due diligence take?

It depends on scope. A light fundraising review of a single product can be done in a week. A full acquisition review of a larger platform, including code scanning, security assessment, and architecture review, typically runs two to four weeks. The biggest variable is access. If the data room is organized and the team is responsive, it moves fast. If documents trickle in one request at a time, it drags.

What is the difference between software and technical due diligence?

Software due diligence focuses on the artifact: the code, its security, and its ability to scale. Technical due diligence is broader and also covers the engineering team, infrastructure, DevOps maturity, and roadmap. On a small deal the same reviewer handles both. On a larger one, software diligence is the deep code-and-security cut inside the wider technical review.

Does the buyer get to see our actual source code?

Sometimes, but not always, and rarely without controls. Many reviews are done through automated scanning tools that report on quality and vulnerabilities without a human reading every line. When direct access is granted, it is read-only and tightly permissioned, often through a data room so every view is logged. Reasonable buyers understand that source code is your crown jewel and will accept a controlled process.

What is a software composition analysis tool?

It is software that scans a codebase to inventory every third-party and open-source dependency, then flags their licenses and any known vulnerabilities. It is the standard way to catch hidden license liability (like copyleft code in a proprietary product) and stale libraries with security holes. Almost every serious software review runs one.

How do I prepare for software due diligence as a founder?

Run a version of the review on yourself first. Inventory your open-source licenses, patch obvious vulnerabilities, confirm every line of code is owned by the company through signed assignment agreements, and write down the architecture so you are not improvising. Then put it all in an organized data room before the buyer asks. The findings you fix yourself never become negotiating leverage for the other side.

Can software due diligence change the deal price?

Yes, and it regularly does. Findings get translated into deal language: a remediation cost the buyer will incur, a valuation adjustment, an escrow holdback, or in serious cases a reason to walk. The point of the review is to price risk accurately, so a thorough software diligence often shifts terms even when the deal still closes.