A software business can look healthy in a sales deck while carrying years of hidden technical risk.
Revenue may be growing, customers may be happy, and the product may appear stable in a demo. Behind that interface, one contractor could hold every production credential, backups may never have been restored, and the main application may depend on an unmaintained library nobody knows how to replace.
Technical due diligence turns those unknowns into commercial decisions before the deal is signed.
What Technical Due Diligence Is For
The goal is not to declare a codebase "good" or "bad." Most working software contains shortcuts, old dependencies, and decisions the current team would make differently today.
The useful questions are:
- Can the product continue operating after ownership changes?
- What could cause a serious outage, breach, or customer loss?
- How difficult and expensive will the planned roadmap be?
- Which people, vendors, and systems are critical dependencies?
- What investment is required in the first 30, 90, and 180 days?
The output should connect technical findings to cost, timing, and business risk. A list of lint warnings is not due diligence.
1. Confirm Ownership and Access
Start by establishing what the business actually owns and controls.
Review access to:
- Source code repositories and commit history
- Cloud hosting and deployment platforms
- Domain registrar and DNS
- Databases, storage, and backups
- Email delivery, payments, analytics, and monitoring
- Mobile app store accounts where relevant
- Third-party API and integration accounts
- Documentation and design assets
Check whether accounts belong to the company or to an employee, agency, or founder personally. Verify that at least two authorised people can administer critical services and that access can be transferred without recreating the platform.
The contract should also address intellectual property. Code in the repository is not automatically owned by the target business if contractors were engaged without appropriate assignment terms.
2. Understand the Architecture
Ask for an architecture walkthrough before reading individual files. The team should be able to explain:
- How a user request moves through the system
- Where application code runs
- Where customer data is stored
- How authentication and permissions work
- Which jobs run in the background
- How external services connect
- How changes reach production
Compare that explanation with the actual configuration and code. Architecture diagrams are useful, but cloud consoles, infrastructure files, and deployment settings show what is really operating.
Look for single points of failure, components with no clear owner, and systems that cannot be reproduced from source control.
3. Assess the Codebase for Changeability
Code quality matters because it determines how safely and quickly the next owner can change the product.
Inspect:
- Project structure and separation of responsibilities
- Automated tests around critical workflows
- Dependency age, support status, and known vulnerabilities
- Build reliability and deployment automation
- Database migration history
- Hard-coded credentials or environment-specific settings
- Error handling and logging
- Unfinished rewrites or parallel legacy systems
Do not use line count or test coverage as a score by themselves. A small test suite protecting billing and permissions may be more valuable than thousands of shallow tests. The key question is whether a competent new team can understand the system and release a change without relying on undocumented knowledge.
Commit history also provides useful context. It shows whether the product is actively maintained, which contributors understand the core systems, and whether large parts of the application arrived as unexplained code drops.
4. Verify Security Controls
Security claims need evidence.
At minimum, review:
- Authentication, session handling, and password recovery
- Role and permission enforcement on the server and database
- Secret storage and rotation
- Encryption in transit and at rest
- Staff access to customer and production data
- Dependency and container patching
- Rate limiting and abuse protection
- Security logging and incident response
- Recent penetration tests or security reviews
Test whether one customer can access another customer's records by changing identifiers or calling the API directly. Frontend restrictions are not access control.
If the business serves regulated customers, compare actual practices with contractual promises. A security page may promise controls the production system does not implement, creating both technical and legal exposure.
5. Examine the Data
Data is often the most valuable asset in a software acquisition and the hardest to repair after a mistake.
Understand:
- The primary data model and its consistency
- Data growth and storage trends
- Tenant separation and access policies
- Backup frequency, retention, and location
- Whether restore tests have succeeded
- Data export and deletion processes
- Personal or sensitive information collected
- Data residency and subprocessors
Request evidence of a recent restore, not only a screenshot showing that backups are enabled. Confirm how much data could be lost and how long recovery would take after a database failure.
Review whether the business has the right to retain and use the data it holds. Historical customer information collected without clear consent can become a liability rather than an asset.
6. Reconcile Infrastructure Cost With Revenue
Cloud cost should be reviewed as a system, not a single monthly total.
Break down spending by hosting, database, storage, bandwidth, monitoring, email, AI APIs, and other usage-based vendors. Then calculate cost per active customer or transaction and compare it across recent months.
Watch for:
- Expiring startup credits hiding the real run rate
- Annual contracts missing from monthly reports
- Costs paid through personal accounts
- Pricing tiers close to a large step increase
- AI or third-party API usage with weak limits
- Infrastructure that scales faster than revenue
- Services duplicated after an incomplete migration
A low hosting bill is not always a positive sign. It may reflect missing backups, monitoring, redundancy, or security rather than efficient architecture.
7. Identify People and Vendor Dependencies
Software does not operate itself. Map who knows how to deploy, recover, debug, and administer each critical component.
High-risk patterns include:
- Only one person has production access
- An external agency controls the repository or cloud account
- Critical services use a former employee's email address
- No one remaining understands a legacy subsystem
- The product depends on a niche vendor without an exit path
- Support relies on developers searching production data manually
Interview the people who operate the system, not only management. Ask them to describe the last serious incident, the hardest part of releasing changes, and the technical work they would prioritise with an extra month.
Those answers often reveal more than a polished technical presentation.
8. Test the Handover
A buyer should know whether the platform can survive without its current technical lead.
A practical handover test might ask a new engineer to:
- Set up the application from the documentation
- Run the tests and build locally
- Deploy a harmless change to staging
- Locate logs for a failed request
- Restore a recent backup into a test environment
- Rotate a non-critical credential
Every blocked step identifies missing access, documentation, automation, or knowledge transfer. These gaps can then become conditions of the deal or explicit handover deliverables.
Turn Findings Into Deal Decisions
Classify findings by business impact rather than technical preference:
| Priority | Meaning | Example |
|---|---|---|
| Critical | Could prevent the transaction or requires immediate control | Seller cannot transfer core IP or production access |
| High | Material security, continuity, or cost risk | No tested backups for customer data |
| Medium | Increases delivery cost or slows the roadmap | Fragile manual deployment process |
| Low | Maintainability improvement with limited near-term impact | Inconsistent formatting or minor duplication |
For each material finding, estimate the likely remediation, dependencies, and time window. Some risks justify a price adjustment. Others need a pre-completion fix, a warranty, a transition agreement, or a funded post-acquisition plan.
The strongest due diligence report does not promise certainty. It shows the buyer what is known, what could not be verified, and what those gaps mean for the investment.
Inspect Before You Inherit
Technical debt is not automatically a reason to walk away. A profitable product with a messy codebase may still be an excellent acquisition if the risks are understood and priced correctly.
The danger is inheriting fragile infrastructure, unclear ownership, or unsafe data practices without knowing they exist. A focused technical review before settlement is far cheaper than discovering those problems during the first outage under new ownership.