How to evaluate software before you buy the business

Define the business questions first

A diligence review should begin with the investment thesis. Is the buyer acquiring recurring revenue, proprietary technology, a team, data, distribution, or a platform to integrate? The technical questions and acceptable risks differ for each case.

Identify which failures could change valuation or deal structure: inability to transfer intellectual property, a material breach, unstable revenue-critical infrastructure, prohibited data use, unsupported core technology, or dependence on a departing individual. This prevents the review from becoming an undifferentiated code-quality audit.

Architecture and scalability

Map the deployed architecture, data flows, third-party services, environments, and major trust boundaries. Compare the documented architecture with repositories and cloud resources. Identify single points of failure and components that cannot scale with the business plan.

Review capacity evidence rather than accepting claims that the system is scalable. Examine traffic patterns, database growth, latency, queue depth, rate limits, and the largest historical events. Estimate which investments become necessary under the buyer’s growth assumptions.

• System diagram reflecting production.
• Critical service and integration inventory.
• Current usage and tested capacity.
• Known bottlenecks and scaling costs.
• Environment and tenant-isolation model.

Security, privacy, and data

Review identity and access controls, secrets management, vulnerability handling, logging, incident history, backups, encryption, tenant separation, and administrative access. Verify regulatory or contractual claims against actual controls and evidence.

Understand what data is collected, where it resides, how long it is retained, which subprocessors receive it, and whether deletion commitments can be fulfilled. Confirm the company has rights to use important datasets and model inputs for their current and intended purposes.

• Open high-impact vulnerabilities and remediation history.
• Security incidents, customer notifications, and unresolved obligations.
• Production administrator list and departed-user access review.
• Backup scope and recent restore evidence.
• Privacy commitments compared with implemented behavior.

Code, dependencies, and delivery

Assess repository ownership, branch protection, review practices, testing, build reproducibility, deployment frequency, rollback capability, dependency exposure, and unsupported technology. Sample consequential code paths rather than relying only on broad static metrics.

Technical debt should be translated into business effects: slower roadmap delivery, outage likelihood, hiring constraints, security exposure, or required migration. Estimate remediation as ranges with assumptions because unfamiliar systems rarely support precise forecasts.

• Does the seller control every required repository and package account?
• Can a clean environment reproduce the build?
• Can the team deploy and roll back without one specific person?
• Are critical dependencies maintained and licensed appropriately?
• Do tests protect revenue and data-critical behavior?

People, ownership, and transferability

Interview the people who operate the system, not only leadership. Identify knowledge concentration, likely post-close departures, contractor dependencies, hiring challenges, and undocumented responsibilities. Compare organizational claims with commit history, incident participation, and access records where appropriate.

Verify intellectual-property assignments for employees and contractors and identify code or assets subject to open-source obligations. Legal counsel should assess ownership and licensing; the technical review supplies the inventory and context.

Reliability and operating history

Review incidents, customer-impacting defects, service objectives, monitoring, on-call practices, recovery exercises, and support volume. A lack of incident records may indicate excellent reliability, but it can also indicate weak detection or informal reporting.

Ask the team to demonstrate how they would diagnose a real customer problem and recover a critical data store. Operational demonstrations often reveal more than policy documents.

• Availability and latency trends tied to customer journeys.
• Material incidents and recurring causes.
• Alert quality and response ownership.
• Recovery time and data-loss objectives.
• Infrastructure and third-party concentration risks.

Turn findings into deal decisions

Classify findings into transaction blockers, conditions to close, near-term remediation, integration work, and normal technical debt. For each material item, explain evidence, uncertainty, business impact, likely effort, and dependencies.

Use findings to inform valuation, escrow or indemnity discussions, transition services, retention plans, security commitments, and the first 100-day roadmap. Preserve unresolved unknowns explicitly; an unverified claim is not the same as a passed control.