Technical Due Diligence: What to Check Before Buying a Software Company

Buying a software company means buying a product, a codebase, an infrastructure setup, a data model, a delivery process, and a set of hidden operational habits. Some of that shows up during a product demo. Much of it surfaces only after close, when the buyer has to integrate systems, support customers, scale usage, pass security reviews, or replace the people who kept the system running from memory.

Technical due diligence gives buyers an engineering view of the asset before the deal is finalized. It helps answer practical questions: how expensive will this product be to maintain, where are the security risks, how much work will integration take, and whether the technology can support the business plan behind the acquisition.

What Technical Due Diligence Covers

Technical due diligence is a structured review of a company’s technology. The scope can include source code, architecture, infrastructure, security controls, data handling, development process, documentation, team dependencies, and future roadmap. In an M&A context, the goal is to understand how technology affects deal risk, valuation, integration planning, and post-close investment.

A useful review starts with the buyer’s reason for the acquisition. A strategic buyer may care most about integration with existing platforms. A private equity buyer may focus on scalability, operating costs, technical debt, and dependency on a small development team. A buyer in healthcare, fintech, or another regulated market may need a deeper look at compliance, data privacy, and audit readiness. The same codebase can look acceptable or risky depending on the plan for the business.

That is why technical due diligence should begin with the desired future state. If the target needs to support a larger customer base, the review should examine load handling, bottlenecks, infrastructure cost, observability, and deployment process. If the buyer plans to merge the product into an existing platform, the review should examine APIs, data models, authentication, documentation, and integration effort. If the target handles sensitive data, the review should examine permissions, encryption, logging, vendor risk, and incident response.

A review detached from the deal thesis can produce a long report with limited decision value. A focused review connects engineering findings to business consequences.

The Main Areas to Review

A technical due diligence review usually starts with architecture. The buyer needs to know how the system is organized, how major components communicate, whether documentation matches the system, and how difficult future changes will be. Architecture also shows how much the product depends on workarounds, hard-coded assumptions, manual operations, or knowledge held by individual engineers.

Source code review comes next. This includes maintainability, test coverage, code organization, dependency health, version control practices, and the ease with which new developers can work in the codebase. A product can look polished to users while the underlying code slows every future release. That matters because acquisition plans often depend on adding features, entering new markets, or integrating the product with existing systems.

Infrastructure and DevOps deserve the same attention. A buyer should know where the system runs, how deployments happen, how environments are separated, how backups work, how failures are detected, and how quickly the team can roll back a bad release. Manual deployments, missing staging environments, weak monitoring, and untested backups can turn routine changes into expensive incidents.

Security and compliance should be reviewed through evidence rather than assurances. Useful evidence includes access controls, password and authentication policies, vulnerability management, dependency scanning, audit logs, encryption practices, penetration testing history, compliance documentation, and incident response procedures. In regulated industries, these findings can affect deal terms, remediation budgets, customer trust, and future sales.

Data handling also needs careful review. Buyers should understand where data comes from, how it is stored, how it moves between systems, who can access it, how quality is checked, and how reporting works. Poor data practices can distort business metrics, complicate integrations, and create privacy exposure. Data lineage, retention rules, backups, and permissions matter as much as database choice.

The development process shows whether the team can keep improving the product after close. Ticket hygiene, sprint planning, release cadence, code review, onboarding, documentation, and knowledge sharing all shape delivery speed. Weak process often shows up as delayed releases, recurring bugs, vague ownership, and too much dependence on a few senior people.

Red Flags Buyers Should Watch For

Heavy technical debt is the most common warning sign. Every software company carries some debt, but the question is whether that debt has started to control the roadmap. When the team spends most of its time fixing old decisions, releases slow down and maintenance costs rise. During diligence, buyers should ask which parts of the system require repeated fixes, which components need replacement, and what work has been postponed for years.

Incompatibility with the buyer’s systems can create another costly problem. A target may use a different cloud provider, authentication model, data structure, deployment pattern, or integration style. None of these details should block a deal by default, but they should be priced into the plan. The buyer needs to know how much work will be needed to make systems operate together.

Security gaps and compliance exposure deserve early attention. Weak authorization, exposed endpoints, missing audit logs, broad production access, outdated dependencies, or poor data retention practices can become expensive after close. These issues affect legal exposure, customer confidence, and the buyer’s ability to sell into security-conscious accounts.

Poor documentation creates operational risk. If architecture diagrams, API docs, deployment instructions, and business logic explanations are missing or outdated, the buyer may inherit a system that only the current team understands. That becomes especially dangerous when a founder or lead engineer plans to leave after the transaction.

A narrow team dependency can be just as risky as a technical flaw. If one person controls deployments, understands billing logic, manages infrastructure, or holds key vendor relationships, the buyer should plan for knowledge transfer before close and operational backup after close.

Expensive technology with weak business fit also deserves scrutiny. Some companies adopt tools because they sound advanced, then carry the cost and complexity for years. The right question is whether each major technical choice supports the product, customers, and roadmap. A modern stack with weak governance can still create expensive problems.

How a Due Diligence Process Works

A useful technical due diligence process has three stages: define the target state, audit the current state, and estimate the gap.

The target state comes from the business plan. The buyer explains what needs to happen after the acquisition: growth, integration, compliance improvement, product expansion, cost reduction, or operational stabilization. This gives the engineering review a direction and prevents the team from treating every technical issue with the same weight.

The current state audit looks at the system as it exists today. Engineers review code, architecture, infrastructure, security controls, data flows, documentation, DevOps practices, team process, and cost structure. The work usually involves interviews, repository access, documentation review, infrastructure walkthroughs, and evidence gathering from tools such as CI/CD systems, monitoring platforms, cloud dashboards, and ticket trackers.

The gap assessment turns findings into business decisions. A good report should explain which issues affect deal value, which issues can wait, which issues need attention soon after close, and what budget or timeline the buyer should expect. This is where technical due diligence becomes useful for negotiation, integration planning, and post-close roadmap decisions.

What the Report Should Include

The final output should help both technical and business stakeholders. Executives need a short explanation of the main risks, likely costs, and decision points. Technical leaders need evidence, architecture notes, code review findings, infrastructure observations, and remediation recommendations. Finance and deal teams need ranges for cost, timeline, and staffing impact.

A strong report usually includes an executive summary, risk matrix, architecture assessment, codebase assessment, infrastructure review, security and compliance findings, data review, team and process observations, integration risks, estimated remediation effort, and a prioritized roadmap. The report should separate deal-critical issues from routine improvement work, because every product has imperfections and buyers need to know which ones matter.

The output should also include practical next steps. For example, the buyer may need to patch security gaps before customer migration, replace a legacy component within six months, add monitoring before scaling usage, renegotiate a vendor contract, or retain a key engineer during the transition period. These recommendations should connect to cost, timing, and operational impact.

A Buyer’s Checklist

Before starting technical due diligence, buyers should prepare a short list of questions tied to the acquisition plan. For architecture, ask how the system is structured, where the main dependencies sit, and whether the system can support planned growth. For code, ask how maintainable the codebase is, how much test coverage exists, and how often old components slow new work.

For infrastructure, ask how deployments happen, how environments are managed, whether backups are tested, and how incidents are detected. For security, ask how access is controlled, how sensitive data is protected, how vulnerabilities are handled, and whether audit logs are available. For data, ask where key data lives, how it moves, how quality is checked, and how reporting depends on manual work.

For the team, ask who owns critical parts of the system, how knowledge is shared, how new developers are onboarded, and which people would be difficult to replace. For costs, ask which cloud, vendor, support, and maintenance expenses are expected to rise after acquisition. For roadmap, ask which planned business goals require technical investment.

These questions help the buyer avoid a generic audit and keep the review tied to deal value.

What Sellers Should Prepare

Sellers can make diligence smoother by preparing technical materials before buyers ask for them. Helpful materials include architecture diagrams, data flow diagrams, API documentation, infrastructure maps, deployment instructions, security policies, compliance documentation, repository summaries, dependency lists, vendor contracts, incident history, and known technical debt.

Sellers should also identify who can answer questions about architecture, infrastructure, security, data, and product roadmap. When these responsibilities are spread across several people, the process moves faster and the buyer gets a better view of how the organization operates. When every answer depends on one person, that becomes part of the risk profile.

Good preparation can also improve the seller’s position. Known issues presented with remediation plans create a better impression than surprises discovered late in the process. Buyers usually expect some technical debt; they react better when the seller understands it, has prioritized it, and can explain its business impact.

Cost, Timing, and Access

Technical due diligence often takes two to four weeks, although larger systems, regulated products, or multi-product companies may require a longer review. Cost depends on scope, system complexity, access depth, and the level of reporting required. MEV’s technical due diligence engagements typically fall between $5,000 and $30,000.

Access should be planned carefully. Buyers and reviewers usually need limited access to source code repositories, architecture documentation, infrastructure dashboards, CI/CD pipelines, monitoring tools, logs, issue trackers, API documentation, security materials, and relevant product documentation. The access model should protect sensitive information while giving reviewers enough evidence to form useful conclusions.

The best access is organized before the review begins. Delays in repository access, missing documentation, or unavailable technical contacts can reduce the depth of the assessment and compress the time available for analysis.

What Good Technical Due Diligence Gives You

Technical due diligence should give the buyer a grounded view of the product they are about to own. It should show what works well, where the system needs investment, which risks affect the deal, and which improvements belong in the post-close plan.

For buyers, the value comes from better decisions. A technical review can support valuation discussions, shape deal terms, guide integration planning, and prevent expensive surprises after close. For sellers, it can help prepare the company for buyer questions and reduce late-stage friction.

Software acquisitions carry technical risk by nature. The goal of diligence is to make that risk visible enough to price, plan, reduce, or accept. When the review is tied to the business plan, buyers get a better view of what they are acquiring and what the product will need after the deal is signed.

This article is adapted from MEV’s original guide to technology due diligence: Technology Due Diligence: How to Do It