Blog

A software company can look like a textbook investment on every metric that reaches the deal team. Recurring revenue climbing. Customer retention holding. A product people demonstrably use. An engineering team that ships. A market with room to grow.

None of that tells the buyer whether the technology underneath is an asset or a liability.

The product might work beautifully today while quietly accumulating the kind of technical debt that makes every future release slower and more expensive. The cloud infrastructure might be functional but wildly inefficient, margins that look healthy now eroding steadily as usage grows. The company might be selling software it doesn't fully own, built on contracts it can't transfer and dependencies it can't replace.

These aren't edge cases. They're patterns, and they show up in software due diligence with a regularity that should make any buyer uncomfortable relying on commercial metrics alone. A sound software acquisition requires more than validating the product. Buyers need to understand the condition of the code, the economics of the infrastructure, and the contractual rights supporting the business.

That's the framework this article is built around: Code, Cloud, and Contracts, three checks that, taken together, give a buyer a materially clearer picture of what they're actually acquiring when they acquire a software company.

What Is Software Due Diligence and Why Does It Matter?

Software due diligence is the assessment of a software company's technology assets, architecture, infrastructure, engineering practices, dependencies, and relevant contractual rights. It exists to answer a question the pitch deck is structurally incapable of answering: is the technology underneath this business as sound as the business on top of it?

What buyers need to establish

The core questions are deceptively straightforward. Does the software work as represented? Can the architecture support growth? Will technical debt require significant investment? Are infrastructure costs sustainable at scale? Does the company own or have the right to continue using, its critical technology? Do third-party agreements create operational or transaction risk?

Each of these has a financial shadow. A "yes" keeps the deal thesis intact. A "no" changes the price, the terms, or the decision.

Why commercial metrics aren't enough

Revenue, customer retention, and growth figures tell the buyer how the business is performing commercially. They do not reveal the cost of maintaining the product, the scalability limits of its architecture, or the legal rights behind its software. A company can be growing revenue while its codebase is becoming harder to maintain, its cloud costs are rising faster than its customer base, and a key vendor contract is six months from expiry with no transfer clause.

Commercial performance and technology health are related. They are not the same thing. The three checks that follow are how a buyer sees the difference.

1. Code: Is the Software Technically Sound and Ready to Scale?

The first check examines the product's technical foundation, not whether it works for today's users, but whether it can carry the business the buyer is paying for.

A software platform can serve its current customers reliably while accumulating weaknesses that make future growth expensive, fragile, or both. The architecture that handles ten thousand users may buckle at a hundred thousand. The codebase that ships features every sprint may be doing so on a foundation that's getting harder to maintain with every release.

Assess the codebase and architecture

A thorough code check examines code quality and maintainability, architecture and system design, technical debt, test coverage, documentation, dependency management, API design, scalability bottlenecks, and reliability and performance characteristics. Together, these determine whether the engineering team is building on solid ground or patching over cracks.

Identify technical debt that could affect deal value

Technical debt is not inherently a problem. Every fast-moving software company carries some, and taking it on deliberately, shipping the imperfect thing to learn something real, is often the right call. What matters is whether the debt is manageable or material.

Manageable technical debt is documented, prioritised, and compatible with the product roadmap. The team knows it's there, has a plan, and can point to it on a whiteboard. That's normal. That's healthy, even.

Material technical debt is undocumented, difficult to maintain, actively blocking development, or likely to require major remediation. Nobody has priced it because nobody has fully admitted it exists. That's the kind that shows up in the integration budget as a surprise with a lot of zeroes.

Test whether the product can support future growth

The questions that actually decide feasibility: can the current architecture support projected customer growth? Are critical components dependent on outdated frameworks? Can the engineering team ship changes reliably? Would new features require substantial rework? Are there single points of failure that could take down the product?

If the answer to several of these is "we'd need to rebuild that part," the buyer needs to know before signing, not after.

What should the buyer receive?

A concise code and architecture risk assessment that identifies material findings, their business impact, and the likely remediation effort. Not a list of style violations. A decision tool.

Key takeaway: Code quality matters because it directly influences the future cost, reliability, and development capacity of the acquired software. A product that works today is not the same as a product that will work, affordably and reliably, at the scale the deal thesis assumes.

2. Cloud: Can the Infrastructure Support Growth Without Eroding Margins?

The second check moves from what the software does to where it runs and what that costs.

For SaaS businesses in particular, cloud infrastructure is not a background detail. It's a margin driver. Infrastructure costs that scale poorly can quietly erode the gross margins that made the business attractive in the first place, and the problem only becomes visible at the usage levels the growth plan projects.

Review the cloud architecture

A proper infrastructure review covers the cloud provider and hosting model, compute and storage architecture, database configuration, network dependencies, availability and redundancy, backup and disaster recovery, monitoring and observability, and deployment and rollback processes. Each of these affects whether the platform stays up, recovers from failure, and can grow without a re-architecture project.

Understand the true cost of infrastructure

Beyond architecture, the buyer needs to understand the economics: monthly cloud spending, infrastructure cost per customer or transaction, idle or overprovisioned resources, data transfer and storage expenses, reserved capacity and commitment obligations, third-party infrastructure services, and, critically, forecast costs at higher usage levels. The question isn't "what does infrastructure cost today?" It's "what will it cost when the business reaches the scale the valuation assumes?"

Look for cloud risks that may not appear in financial statements

Some infrastructure risks are invisible until they become expensive. Single-region dependencies that turn a provider outage into a business outage. Inadequate disaster recovery that nobody tests because nobody wants to find out. Weak access controls. Unexpected egress charges. Vendor lock-in that makes migration prohibitively costly. Limited observability that means the team can't diagnose problems they can't see. Infrastructure that technically works but can't scale without a significant re-engineering effort.

Connect infrastructure findings to the investment thesis

The infrastructure assessment should mirror the reason for the deal. For a growth investment, determine whether the infrastructure can support expansion without disproportionate cost increases. For a cost-synergy acquisition, identify opportunities to consolidate cloud environments or eliminate redundant spending. For a strategic acquisition, assess whether the target's infrastructure can integrate with the buyer's existing technology estate.

Key takeaway: A technically functional platform is not necessarily an economically sustainable one. Cloud infrastructure is where the gap between "it works" and "the margins work" tends to live.

3. Contracts: Does the Company Own and Control the Technology It Sells?

The third check examines the legal and commercial foundations of the software business. A buyer may acquire a functioning product and discover, sometimes well after closing, that important components depend on third-party rights, restrictive licences, or incomplete ownership documentation.

Verify intellectual property ownership

Review the full chain of ownership: employee IP assignment agreements, contractor and agency agreements, founder contributions, source-code ownership, patents and proprietary algorithms, open-source software licences, and third-party software licences. The classic trap is the contractor, an enormous amount of early-stage software is built by outside agencies and freelancers, and if those relationships didn't include proper IP assignment, the company may not own the code it's presenting as proprietary.

Examine critical vendor and cloud contracts

Check for change-of-control clauses that could be triggered by the acquisition itself, assignment restrictions, termination rights, renewal dates, price escalation provisions, service-level commitments, data-processing obligations, and portability and exit provisions. A contract that works perfectly well for the current owner can become a liability when ownership changes hands.

Investigate third-party technology dependencies

Does the product depend on proprietary APIs whose provider could change terms or discontinue the service? Are critical licences transferable? Are open-source obligations being met? Does the company actually control its source-code repositories? Are customer data rights and software rights clearly defined? Each dependency is a question about what happens if the dependency changes, and in a post-acquisition environment, dependencies tend to change.

Understand the implications for the transaction

Unresolved IP or contract issues may require legal remediation, additional licensing costs, revised transaction terms, or changes to the post-close integration plan. Technology diligence identifies the risks; legal counsel interprets the contractual implications and advises on transaction protections. The two workstreams are distinct and both necessary.

Key takeaway: The buyer must understand not only whether the software works, but also whether the company has the rights needed to continue operating and developing it after the deal closes.

How Code, Cloud and Contracts Interact

The three checks are not isolated workstreams. They interact, and the interactions are often where the most material findings live.

Good code, expensive cloud: The software is well engineered, but inefficient infrastructure drives up operating costs. The product may require cloud optimisation before margins improve to the levels the deal model assumes.

Scalable platform, restrictive contract: The architecture can support growth, but a critical third-party licence cannot easily be transferred to a new owner. Expansion or integration may depend on renegotiating an agreement the buyer didn't know about during the commercial negotiation.

Strong product, unclear IP ownership: The product works and has customers, but key components were developed by contractors without clear IP assignment. Ownership must be resolved before the buyer can confidently value the technology asset, and resolution may not be cheap or fast.

Modern architecture, limited operational resilience: The application uses modern cloud services but lacks reliable recovery procedures or adequate monitoring. The buyer may inherit operational risks despite a technically modern technology stack.

The value of software diligence comes from understanding the combined effect of technical, infrastructure, and contractual risks, not from treating each as a standalone exercise.

How Software M&A Due Diligence Differs From a Routine Technical Review

Software M&A due diligence goes beyond determining whether a product is technically sound. It connects technology findings to valuation assumptions, transaction risks, integration requirements, and the future investment needed to operate the acquired business.

Focus on the deal thesis

Diligence should reflect the reason for the acquisition, not run from a generic template. A growth acquisition calls for depth on scalability, roadmap feasibility, and engineering capacity. A cost-synergy acquisition needs focus on cloud economics, application duplication, and vendor rationalisation. A strategic technology acquisition demands scrutiny of IP ownership, proprietary capabilities, and technical differentiation. A SaaS acquisition requires attention to reliability, customer data handling, recurring infrastructure costs, and multi-tenancy architecture.

Same product. Different thesis. Different review.

Translate findings into deal decisions

For each material finding, establish what was discovered, what the business impact is, what remediation is required, the estimated cost and timeline, and whether the finding affects valuation, deal terms, or integration planning. That translation is what turns a technical report into something an investment committee can act on. A finding without a dollar figure and a severity level is trivia that happens to be in a report.

How to Apply the Three-Check Framework to Minority Growth Investments

Minority investments carry a different risk profile from full acquisitions. The investor may not control the company or its technology decisions, but the investment is still exposed to every technology risk the business carries.

What minority investors should prioritise

Code: Product scalability, technical debt, engineering capacity, and roadmap feasibility. Can the team build what the growth plan promises?

Cloud: Infrastructure cost trends, reliability, security posture, and capacity for growth. Will margins hold as usage scales?

Contracts: IP ownership, critical vendor dependencies, licensing obligations, change-of-control provisions, and existing contractual restrictions. Is the technology asset structurally sound?

Why governance and visibility matter

A minority investor should understand what technology information will be available after the investment, how material risks will be reported, and whether the company has a credible remediation roadmap for the issues diligence identifies. The scope of diligence should be proportionate to the investment size, technology complexity, and risk profile, not identical to a full acquisition review, but not a cursory glance either.

Choosing the Right Diligence Partner for a Software Investment

Investors evaluating software companies, whether through full acquisitions or minority growth transactions, should look for best technical due diligence services for minority growth investments that can assess code quality, cloud economics, IP and vendor dependencies, and the technology requirements behind the company's growth plan.

What to evaluate when selecting a provider

Look for experience with software and SaaS businesses, M&A and growth-investment experience, code and architecture assessment capabilities, cloud infrastructure and cost expertise, IP and licensing risk identification, understanding of minority-investment dynamics, the ability to prioritise material findings over noise, and clear reporting calibrated for investment committees rather than engineering teams.

Questions to ask before engagement

Interrogate the provider the way you'd interrogate the target. What technology areas are included in scope? Will the team examine source code or rely on interviews and documentation? How will cloud costs and scalability be assessed? How will IP and contractual risks be identified? How are findings ranked by severity? Will the report quantify remediation effort? Can the review be completed within the transaction timeline?

On that last point, the one that separates a useful report from a frightening one, the best diligence providers are the ones who tell you which problems are a Tuesday-afternoon engineering fix and which are why-the-margins-don't-work, instead of handing you fifty undifferentiated red items and an invoice. A findings list with no priorities isn't diligence; it's anxiety with a cover page. (Dextra Labs, as a technical due diligence service provider, would want you to know they feel quite strongly about this particular distinction, they've seen enough undifferentiated red to last a career.)

Avoid choosing a provider solely on brand recognition or price. Compare the actual team, scope, methodology, and deliverables.

A Practical Code, Cloud & Contracts Due Diligence Checklist

A working checklist the deal team can use directly:

Final Takeaway: Three Checks, One Investment Decision

Software due diligence is most valuable when code quality, cloud economics, and contractual rights are evaluated together. A strong codebase cannot compensate for unsustainable infrastructure costs. A scalable platform is not a secure investment asset if ownership or licensing rights remain uncertain. And a clean set of contracts means little if the software underneath can't carry the growth the deal thesis assumes.

The buyer should leave diligence with a clear understanding of what technology the company owns, whether the software can support growth, what the infrastructure will cost at scale, which dependencies create risk, what remediation is required, and how the findings affect the investment thesis.

The goal was never to find a flawless technology stack. There isn't one, not at any stage worth investing in. The goal is to understand the true cost, risk, and potential of the software asset before the money moves, rather than discovering them in the integration budget after.

Frequently Asked Questions

What is software due diligence?

Software due diligence is a structured assessment of a software company's technology assets, including its codebase, architecture, infrastructure, engineering practices, third-party dependencies, intellectual property, and contractual rights. It helps buyers and investors understand the condition, risks, and future investment requirements of the technology before completing a transaction.

What does software M&A due diligence include?

Software M&A due diligence typically covers code quality and architecture, technical debt, cloud infrastructure and costs, cybersecurity, IP ownership, open-source and third-party licensing, vendor contracts, engineering team capability, scalability, and the alignment of technology with the deal thesis. The scope should be tailored to the specific transaction.

How do buyers evaluate code quality during an acquisition?

Buyers evaluate code quality through source-code review, architecture assessment, technical-debt analysis, test-coverage evaluation, dependency auditing, and engineering-practice review. The assessment should identify material issues that could affect maintainability, scalability, security, or the product roadmap.

Why are cloud costs important in software due diligence?

Cloud infrastructure costs directly affect gross margins and future profitability, particularly for SaaS businesses. Costs that scale disproportionately with usage can erode the margins that justified the valuation. Diligence should assess current spending, cost-per-customer economics, and forecast infrastructure costs at projected growth levels.

What contracts should buyers review when acquiring a software company?

Buyers should review IP assignment agreements, contractor and agency agreements, open-source licences, third-party software licences, cloud and hosting contracts, vendor agreements with change-of-control or assignment clauses, data-processing agreements, and any contracts involving critical technology dependencies.

How does due diligence differ for minority growth investments?

Minority growth investors typically cannot control the company's technology decisions, so diligence focuses on understanding the risks attached to the investment rather than planning integration. Key areas include product scalability, technical debt, infrastructure cost trends, IP ownership, critical vendor dependencies, and whether the engineering team can deliver the growth roadmap.

Who should conduct technical due diligence for a software acquisition?

The choice depends on the complexity of the target's technology, the transaction timeline, and the buyer's internal capabilities. Specialist technology due diligence providers are particularly valuable for complex software architectures, AI/ML systems, significant cybersecurity exposure, unclear IP ownership, or transactions where technical findings could materially affect the deal decision.