Pre-Acquisition Code Review: A Buyer's Guide

You’re buying a software company. The financials check out. The legal team is satisfied. The product demos well. The growth metrics look real.

Then you close the deal, hand the codebase to your engineering team, and discover that the entire thing runs on a single database server with no failover, the “test suite” is twelve tests that haven’t passed in six months, and the deployment process lives in one developer’s head — a developer who just hit their retention cliff.

This happens more often than anyone in M&A wants to admit. The pattern is consistent: confident close, ugly discovery, expensive cleanup. We’ve run dozens of code audits for acquiring companies, and the ones who review the code before signing spend a fraction of what the ones who skip it spend on remediation after.

Why Code Review Before Acquisition Matters

In a software acquisition, the code is the asset. You’re not buying a logo or a customer list (well, not just those). You’re buying architecture decisions, test suites, deployment pipelines, security posture, and years of accumulated technical choices. The quality of those choices determines how much engineering investment you’ll need post-close.

Seller representations about code quality are unreliable. Not because sellers lie — most don’t. But because they have a different definition of “good.” When you’ve worked in a codebase for three years, you know where the landmines are. You route around them instinctively. To you, the code works. To a new team inheriting it cold, it’s a minefield without a map.

The demo is polished. The metrics are real. But none of that tells you what’s underneath. We’ve reviewed codebases backing $10M+ revenue products where the deployment process was “SSH into prod and run a shell script,” the payment integration had never been tested against Stripe’s error responses, and the only person who understood the data model was a contractor whose engagement ended three months ago.

Most M&A teams do financial and legal due diligence rigorously. They’ll spend $200K on legal review without blinking. But the technical assessment of the actual asset — the code — gets treated as an afterthought. A focused code review during the LOI phase is the highest-ROI spend in the entire deal process. It either confirms your assumptions or gives you concrete reasons to reprice.

If you’re involved in technical due diligence for software acquisitions, the code review is where abstract risk becomes concrete cost.

Before You Get Access to the Code

You don’t need repository access to start evaluating. The LOI phase is your opportunity to gather information that shapes the scope of the technical review and surfaces red flags early.

Technical Questionnaire

Include these questions in your LOI process or early due diligence requests:

• Languages, frameworks, and infrastructure. What’s the stack? How old are the framework versions? Are they on supported releases?
• AI-generated code. How much of the codebase was written or substantially modified by AI tools? Which tools — Copilot, Cursor, Claude, ChatGPT? This matters more than most buyers realize. AI-generated code has specific patterns of risk that differ from human-written code.
• Test coverage. What percentage? More importantly, what’s tested — is it the happy path, or the edge cases that cause production incidents?
• CI/CD maturity. Is there a pipeline? Does it run tests? Can they deploy with a button push, or does it require manual steps?
• Team composition. How many active contributors in the last 90 days? What’s the bus factor — how many people would need to leave before critical knowledge is lost?
• Security history. When was the last security audit? Penetration test? Have there been any breaches or data incidents?
• Operational metrics. What’s the deployment frequency? Average incident recovery time? How many production incidents in the last quarter?

Vague answers to any of these are themselves a finding. A team that can’t tell you their test coverage or deployment frequency probably doesn’t have good numbers.

What to Request in the Data Room

Beyond just “code access,” ask for:

• Repository access (read-only is fine for initial review)
• Infrastructure diagrams — how the system is deployed, what talks to what
• CI/CD pipeline configuration — the actual config files, not a description
• Incident history for the past 12 months — including severity, root cause, and resolution time
• Dependency manifest or SBOM (Software Bill of Materials) — what third-party code is in the product
• Last security audit report — if one exists

Structuring Code Access

Sellers worry about IP exposure, and that’s legitimate. Address it directly. Propose read-only repository access via time-limited tokens, under a mutual NDA with specific IP protection clauses. The review team should be named individuals, not “our contractors.” Limit access to the assessment window — typically 1-2 weeks — with tokens that expire automatically.

If a seller refuses code access entirely, that’s a significant red flag. You wouldn’t buy a building without an inspection. The same logic applies to software.

The Five Dimensions of Code Evaluation

We use a five-dimension framework for pre-acquisition code review. Each dimension gets a rating and a cost estimate for remediation. Together, they give you a complete picture of what you’re buying.

1. Architecture

Is there a coherent design, or did the codebase evolve without a plan?

• Component coupling. Can you change the billing module without touching authentication? Tight coupling means every change is expensive and risky.
• Single points of failure. One database server, one message queue, one person who understands the payment integration. Each one is a risk that needs pricing.
• Scalability architecture. Is the system designed to scale horizontally, or does scaling mean “buy a bigger server”?
• Service boundaries. If it’s microservices, are the boundaries logical? Or is it a distributed monolith — the worst of both worlds?
• Data flow clarity. Can you trace a request from browser to database and back? If that path crosses fifteen services, you need to understand why.

Architecture problems are the most expensive to fix. A fundamentally flawed architecture can require a rewrite — a six-figure engagement that takes months.

2. Security

Every security finding becomes either a negotiation point or a post-close cost. Both matter.

• Liability exposure. Are there active vulnerabilities that affect customer data? Undisclosed security issues become the acquirer’s problem at close. Map each finding to potential regulatory and legal exposure.
• Credential hygiene. How are secrets managed — vault, environment variables, or hardcoded in source? The answer tells you more about the team’s security maturity than any self-assessment questionnaire.
• Attack surface. How many external-facing endpoints exist? Are they rate-limited, validated, and authenticated? An API with no input validation is an open door.
• Dependency risk. How many known CVEs sit in the dependency tree? How stale are the packages? Abandoned dependencies are a recurring remediation cost, not a one-time fix.
• Compliance posture. Does the security implementation match what the seller represents to customers? If the marketing site says “bank-grade encryption” and the database stores passwords in plaintext, that’s a misrepresentation with legal implications.

Security issues that haven’t been disclosed to customers — active vulnerabilities that affect user data — are potential walk-away findings. They represent undisclosed liability.

3. Scalability

The product handles current load. Will it handle yours?

• Database design and query patterns. Missing indexes, N+1 queries, full table scans. The most common performance problems and the easiest to spot in a code review.
• Caching strategy. Is there one? Is it coherent? Cache invalidation problems cause some of the most confusing production bugs.
• Horizontal scaling capability. Can you add servers to handle more traffic? Sticky sessions, local file storage, and in-memory state all block horizontal scaling.
• Bottleneck identification. Where will the system break first under 10x load? 100x? Every system has a bottleneck — the question is whether fixing it is straightforward or architectural.

If you’re buying a product doing 1,000 requests per minute and you plan to drive it to 50,000, you need to know whether the architecture supports that — or whether you’re buying a rewrite.

4. Maintainability

Can your team actually work in this codebase?

• Code consistency. Does every file look like a different developer wrote it on a different day? Inconsistency slows everyone down.
• Documentation. Not marketing docs — internal documentation. Are complex business rules explained? Can a new developer understand why things were built this way?
• Test quality. Coverage numbers lie. 80% coverage testing only happy paths is worse than 40% coverage testing failure modes.
• Error handling. Are errors caught gracefully, or does the app crash and show stack traces to users?
• Code organization. Can you find the code for a given feature without searching every directory?

Poor maintainability doesn’t just slow you down — it causes your best engineers to push back on working in the codebase at all.

5. Operational Readiness

How much operational investment is needed post-close?

• Monitoring and alerting. Do they know when the system is unhealthy before users report it?
• Backup and restore. Are backups automated? Has anyone tested a restore recently? An untested backup is not a backup.
• Disaster recovery. What happens if the primary datacenter goes down? Is there a runbook?
• CI/CD maturity. Can a developer push code and have it deployed automatically with tests? Or is deployment a manual, multi-step process?
• Infrastructure-as-code. Is infrastructure defined in Terraform or similar? Or was it configured by hand in a cloud console?

A system with no monitoring, manual deployments, and untested backups requires significant investment before it meets the standard most acquiring companies expect.

Integration Cost Estimation

The audit findings are useful. But what deal teams actually need is a cost estimate. Here’s how to translate findings into numbers.

Categories of Post-Acquisition Engineering Work

Immediate — Month 1. Critical security fixes, production stability issues, access control changes (rotating credentials, removing former employee access). These are non-negotiable. Budget $50K-$150K in engineering time depending on severity.

Short-term — Months 1-3. CI/CD integration with your existing pipelines, monitoring and alerting setup, team onboarding and knowledge transfer, documentation of undocumented systems. Budget $100K-$300K.

Medium-term — Months 3-6. Architecture refactoring, test suite improvements, technical debt reduction, compliance alignment if the acquiring company has different requirements (SOC 2, HIPAA, etc.). Budget $200K-$500K.

Long-term — Months 6-12. Platform integration with the acquirer’s systems, feature alignment with product roadmap, scale optimization for the acquirer’s growth targets. Budget varies widely based on integration scope.

The Hidden Multiplier

Acquired codebases always take longer than estimated. Always. Your team has to learn the codebase while simultaneously fixing it. They’re discovering undocumented behaviors while trying to change them.

Rule of thumb: take your engineering estimate and add 40-60% for ramp-up overhead. If the plan says “six months,” model it as nine. If it says “$400K,” model it as $600K. Your CFO will thank you when the actuals come in.

Converting Findings to Headcount

Each finding category maps to engineering effort:

• Critical security fix: 1-2 engineers, 1-2 weeks each
• Architecture refactoring: 2-3 engineers, 4-8 weeks
• Test suite buildout: 1-2 engineers, 4-6 weeks
• CI/CD setup: 1 engineer, 2-3 weeks
• Monitoring/alerting: 1 engineer, 1-2 weeks

Sum these up, apply the ramp-up multiplier, and you have a headcount plan that feeds directly into your financial model.

Negotiation Points From Code Findings

A pre-acquisition code review isn’t just risk mitigation. It’s a negotiation tool. Every finding has a dollar value, and that dollar value affects the deal.

Findings That Warrant Valuation Adjustments

• Critical security vulnerabilities. Unpatched known exploits, SQL injection in production, exposed credentials. These represent immediate remediation costs and potential liability.
• Architecture that requires rewrite. If the system can’t scale to your targets without a fundamental rebuild, that’s a six-figure cost that should be reflected in the purchase price.
• Missing test coverage on revenue-critical paths. If the payment processing flow has zero tests, you’re accepting risk that changes to that flow could break revenue. Price it.
• Significant undisclosed technical debt. If the seller represented the code as production-ready and it’s not, that’s a material misrepresentation worth a price adjustment.

Findings That Warrant Earnout Structures

• Key developer dependencies. If one engineer holds critical knowledge, structure part of the deal as retention-based earnout for that individual.
• Undocumented systems. If critical business logic exists only in someone’s head, tie part of the payment to successful knowledge transfer over 6-12 months.
• Integration complexity. If the integration requires the seller’s team to cooperate actively, structure the deal so their incentives align with a successful integration.

Findings That Warrant Walk-Away Consideration

• IP ownership uncertainty. If significant portions of the code were generated by AI tools and the IP implications are unclear, that’s unquantifiable risk. This is increasingly common — due diligence on AI-generated codebases is becoming a required part of the process.
• Undisclosed security breaches. If the codebase shows evidence of breaches that weren’t disclosed to customers or regulators, you’re potentially acquiring undisclosed legal liability.
• Single-person dependency with no retention. If the entire system depends on one developer who won’t be staying post-acquisition, you’re buying a codebase nobody can maintain.

Translating Technical Findings for Deal Teams

Non-technical stakeholders don’t need to understand SQL injection vs. XSS. They need cost and risk. Frame every finding as:

1. What it is — one sentence, plain English
2. What it costs — dollar range to remediate
3. What it means for the deal — price adjustment, structural change, or walk-away trigger

Example: “The application has three critical security vulnerabilities that expose customer data. Fixing them requires $80K-$120K over 4-6 weeks. This warrants a purchase price adjustment, and the seller should disclose whether these vulnerabilities have resulted in data exposure.”

That’s language a deal team can act on.

Timeline and Process

A pre-acquisition code review is a focused engagement with a defined scope and timeline. Here’s what it looks like in practice.

Typical Timeline

• Week 0: NDA execution, data room setup, access provisioning
• Week 1: Automated scanning, architecture review, security assessment, code quality analysis
• Week 2: Deep-dive on critical findings, integration cost estimation, report drafting
• Week 3: Report delivery, walkthrough with deal team, Q&A session

For smaller codebases (under 100K lines), this compresses to 1-2 weeks. For larger or more complex systems, it may extend to 3-4 weeks.

Access Requirements

Request these in order:

1. Mutual NDA with specific IP protection clauses
2. Data room access for documentation and infrastructure details
3. Read-only repository access via time-limited tokens for named individuals
4. 30-60 minute call with the lead engineer to ask clarifying questions (not required, but significantly accelerates the review)

Coordinating With Other DD Workstreams

Technical DD doesn’t exist in isolation. Coordinate with:

• Financial DD — Your cost estimates feed their model. Share findings early enough to be incorporated.
• Legal DD — IP ownership questions (especially around AI-generated code and open-source licenses) need legal interpretation.
• Operational DD — Infrastructure costs, hosting contracts, and vendor dependencies all have financial implications.

Independent Review vs. Internal Team

Internal engineers know your architecture and integration requirements. Independent reviewers have no political dynamics — they won’t soften findings to avoid internal conflict or “not invented here” bias.

The strongest approach: independent review with internal consultation. Let an outside team do the assessment, then validate integration cost estimates with your engineering leadership.

Our code audit process is designed for exactly this — time-boxed, independent, and structured to produce output that non-technical deal stakeholders can act on.

Managing Seller Sensitivity

Sellers get nervous about code review. They’re worried about IP exposure and findings being used to unfairly renegotiate. Address this head-on:

• Name the reviewers. Specific individuals, not “our team.”
• Time-limit access. Tokens expire when the review ends.
• Share the methodology. Sellers relax when they know what you’re evaluating and how.
• Offer to share the report. Many sellers appreciate the findings — it’s a free code audit if the deal doesn’t close.
• Keep it professional. This is an assessment, not a prosecution.

Most sellers who resist initially come around when the process is presented professionally. The ones who refuse entirely — that tells you something too.

Planning a software acquisition? Variant Systems provides independent pre-acquisition code reviews that give your deal team the technical intelligence they need. We work under NDA, on your timeline, and deliver reports your investment committee can act on.