You wouldn’t acquire a company without reviewing their financials. But you’d be surprised how many deals close without anyone looking at the code.

The software is often the most valuable asset in the deal. It’s also the one most likely to hide expensive surprises. Technical debt that doubles development costs. Security vulnerabilities that create liability. A codebase so tangled that the team can’t ship new features without breaking existing ones. An architecture that works at current scale but will collapse at 5x.

Financial auditors know what to look for in a balance sheet. Most deal teams have no technical due diligence software or process for evaluating a codebase. This checklist helps.

Why technical due diligence matters

A 2023 study by Bain found that 70% of technology M&A deals fail to deliver expected value. Poor technology integration is consistently cited as a top reason. But integration problems often start before the deal closes, with risks that were there to find but nobody looked.

Common post-acquisition surprises:

Rewrite costs. The codebase looked functional during the demo but turns out to be unmaintainable. Estimated rebuild: $2M and 18 months.
Security exposure. Unpatched dependencies with known CVEs. A breach after acquisition means you inherited the liability.
Key person dependency. One developer wrote 80% of the core system. They weren’t part of the retention package. They left after month 3.
License violations. A library used commercially without the right license. Legal exposure discovered during the first compliance audit.
Hidden technical debt. Every feature takes 3x longer than estimated because of workarounds baked into the architecture. The burn rate doubles.

Every one of these is discoverable before signing. You just have to look.

The checklist

1. Architecture health

What to check:

Can the team explain the system architecture in a simple diagram?
Are major components separated and independently deployable?
Is the architecture documented, or does it only exist in one person’s head?
How tightly coupled are the components? Can you replace one without rewriting others?

Red flags:

No architecture diagram exists
“Monolith” that started small but grew organically with no refactoring
Circular dependencies between modules
All business logic mixed into the UI layer

What it tells you: Whether the software can evolve or whether you’re inheriting a structure that resists change.

2. Code quality and complexity

What to check:

Average function and file sizes (are there 1,000-line files or 500-line functions?)
Consistency of coding patterns across the codebase
Amount of code duplication
Number and severity of TODO/FIXME/HACK comments (markers of acknowledged debt)

Red flags:

Files exceeding 1,000 lines
Inconsistent naming conventions suggesting multiple developers with no standards
High duplication indicating copy-paste development
Hundreds of TODO comments that have never been addressed

What it tells you: How expensive the codebase will be to maintain and extend after acquisition.

3. Security posture

What to check:

Number of known vulnerabilities in dependencies (CVEs)
Are secrets (API keys, tokens, passwords) hardcoded in source?
Authentication and authorization implementation
Data encryption practices
OWASP Top 10 exposure

Red flags:

Any critical or high-severity CVEs in production dependencies
Hardcoded credentials in the repository
Rolling your own authentication instead of using established libraries
No Content Security Policy or CORS configuration
User input not sanitized

What it tells you: Your liability exposure from day one. Security issues don’t go away at acquisition. They become your problem.

4. Dependency health

What to check:

What percentage of dependencies are outdated?
How many major versions behind are critical dependencies?
Are there dependencies with restrictive licenses (GPL, AGPL) that conflict with commercial use?
How many dependencies does the project have? (fewer is generally better)

Red flags:

More than 40% of dependencies outdated
Any critical dependency more than 2 major versions behind
GPL/AGPL licensed dependencies in a proprietary product
End-of-life runtime versions (Node.js, Python, etc.)

What it tells you: How much invisible maintenance work you’re inheriting. Outdated dependencies are compound interest on technical debt.

5. Test coverage

What to check:

Do automated tests exist at all?
Are the critical business logic paths tested?
What types of tests? (unit, integration, end-to-end)
When were tests last updated? (stale tests give false confidence)

Red flags:

No tests at all
Tests exist but haven’t been updated in months (they probably don’t pass)
Only happy-path tests with no edge case coverage
Critical revenue-generating flows untested

What it tells you: How safe it is to make changes. No tests means every modification is a gamble.

6. Team and knowledge distribution

What to check:

How many active contributors over the last 6-12 months?
Is code ownership distributed or concentrated in one person?
How long does a new developer take to become productive?
Is documentation sufficient for someone outside the current team to understand the system?

Red flags:

One person authored more than 70% of a critical subsystem
Key contributors not included in the retention package
No documentation beyond code comments
Onboarding time exceeds 3 weeks

What it tells you: Whether the knowledge transfers with the deal or walks out the door.

7. Scalability indicators

What to check:

How does the system handle current load?
Are there known bottlenecks at higher scale?
Is the database schema designed for growth?
Does the deployment pipeline support rapid iteration?

Red flags:

No monitoring or alerting in production
Manual deployment process
Database queries without indexes on large tables
No caching strategy

What it tells you: Whether the software can grow with your business plan or will need a rewrite at scale.

How to run the assessment

Option 1: Technical team member. If someone on your deal team can read code, give them this checklist and 2-3 days with the repository. Cheap but limited to one person’s judgment.

Option 2: External consultant. Hire a code audit firm. Thorough but expensive ($10,000-50,000 for a full assessment) and slow (3-6 weeks). Appropriate for large deals.

Option 3: Automated analysis first, then targeted expert review. Run an automated code health analysis to get a baseline across all seven areas. Use the findings to focus the expert review (Option 2) on the areas that matter. This is faster and cheaper because the consultant spends their time on judgment calls, not rediscovering things a tool finds in minutes.

StackGrit produces a structured health report covering architecture, code quality, security, dependencies, test coverage, and team knowledge distribution. The report is written in plain language for non-technical readers. Connect the target’s repository, get a report in under two hours, and use it to decide whether a deeper assessment is worth the investment.

The deal-breaker question

After reviewing the checklist, ask yourself: if you had to rebuild this software from scratch, what would it cost?

If the rebuild cost is a significant percentage of the acquisition price, the code quality is directly affecting the deal economics. A $5M acquisition with $2M in hidden rebuild costs is really a $7M acquisition. Your offer should reflect that.

Most acquirers don’t ask this question because they don’t have the data to answer it. A code health report gives you that data before you sign.

Evaluating a software asset? Get an independent health report before you write the check. First analysis is free, no credit card.

Run your due diligence analysis →