---
title: "How to Run a Technical Due Diligence Before Acquiring a Startup"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2026-05-20"
category: "AI & Strategy"
tags:
  - technical due diligence
  - startup acquisition
  - M&A technology assessment
  - pre-acquisition code audit
  - due diligence checklist
excerpt: "Acquiring a startup without a rigorous technical due diligence is like buying a house without an inspection. Here is the exact process smart buyers follow to avoid seven-figure surprises."
reading_time: "15 min read"
canonical_url: "https://kanopylabs.com/blog/how-to-run-technical-due-diligence-before-acquisition"
---

# How to Run a Technical Due Diligence Before Acquiring a Startup

## Why Technical Due Diligence Is Non-Negotiable for Acquisitions

If you are acquiring a startup, the technology is usually the asset you are paying for. Not the brand. Not the office lease. The codebase, the data, the infrastructure, and the engineering team. And yet a surprising number of acquirers treat technical due diligence as an afterthought, delegating it to a quick code scan or skipping it entirely because "the CTO seemed sharp in the interview."

That is how you end up owning a product built on a framework that was deprecated two years ago, held together by a single developer who just vested and is about to leave. I have seen acquisitions where the buyer discovered post-close that the entire application was running on a single EC2 instance with no automated backups, no CI/CD pipeline, and database credentials hardcoded into the source code. The cost to remediate exceeded 40% of the purchase price.

![Business team reviewing technical documents during a startup acquisition due diligence process](https://images.unsplash.com/photo-1553877522-43269d4ea984?w=800&q=80)

Technical due diligence for acquisitions is fundamentally different from the TDD that happens during fundraising. When an investor runs TDD on a Series B company, they are evaluating risk in the context of a minority stake. If the technology has problems, the existing team will fix them. But when you are acquiring a company, you are buying the problems. Every line of technical debt becomes your balance sheet liability. Every security vulnerability is now your breach risk. Every missing test is your future outage.

The stakes are higher, the scope is broader, and the timeline is usually tighter. Most acquisition TDD processes run between 2 and 6 weeks, depending on the size and complexity of the target. If you are a PE firm or strategic acquirer doing multiple deals per year, having a repeatable, rigorous TDD process is one of the highest-leverage investments you can make. For a deeper primer on TDD fundamentals, our [complete technical due diligence guide](/blog/technical-due-diligence-guide) covers the basics.

## The Pre-Engagement Phase: Setting Up for Success

Before you send a single engineer into the target company's codebase, you need to get your process right. The pre-engagement phase is where most acquirers either set themselves up for a thorough evaluation or doom themselves to a superficial one.

### Assemble the Right Team

You need at least three distinct perspectives on your TDD team. First, a **senior architect or CTO-level evaluator** who can assess the overall system design, scalability ceiling, and technology choices. This person should have experience with the target's tech stack, but more importantly, they need to have seen enough systems to recognize patterns of health and decay. Second, a **security specialist** who will evaluate authentication, authorization, data handling, encryption, and compliance posture. Third, a **DevOps or infrastructure engineer** who can assess deployment pipelines, monitoring, disaster recovery, and cloud cost efficiency.

If you do not have these people in-house, hire a specialist firm. Boutique TDD consultancies like Kanopy Labs, Lighthouse Labs, or CrossLend Technical Advisory typically charge between $15,000 and $50,000 for a full acquisition TDD engagement. Big 4 firms (Deloitte, PwC, EY, KPMG) offer TDD services as well, but their engagements start at $75,000 and can run well past $150,000 for complex targets. The cost breakdown is covered in detail in our [guide to technical due diligence costs](/blog/how-much-does-technical-due-diligence-cost).

### Define the Scope and Objectives

Before kicking off, write a one-page scope document that answers these questions: What are we acquiring this company for? Is it the product, the team, the data, or the IP? What are the top 3 risks we need to evaluate? What would be a deal-breaker? What is the integration plan, and how does that affect what we need to assess?

A PE firm acquiring a SaaS platform to bolt onto an existing portfolio company has very different TDD priorities than a Fortune 500 company acquiring a startup for its AI models. The PE firm cares about integration complexity, ongoing maintenance costs, and whether the technology can run without the founders. The enterprise acquirer cares about IP ownership, model performance benchmarks, and whether the technology can operate within their security and compliance framework.

### Negotiate Data Room Access

You will need access to the target's codebase, infrastructure, documentation, and key personnel. Negotiate this upfront as part of the LOI (Letter of Intent). The standard approach is read-only access to the primary code repositories, a staging or demo environment, architecture documentation, and scheduled interviews with the CTO and senior engineers. Push for access to their project management tool (Jira, Linear, Shortcut) as well. The commit history and ticket backlog tell you more about engineering health than any slide deck.

## The Six Pillars of Acquisition Technical Due Diligence

Every acquisition TDD should evaluate six core areas. Skip any one of them and you are flying blind on a dimension that could cost you millions post-close.

### 1. Code Quality and Maintainability

Start with automated scanning. Run **SonarQube** or **CodeClimate** against the full codebase to get baseline metrics on complexity, duplication, code smells, and test coverage. These tools give you a quantitative starting point, but they are not sufficient on their own. You need experienced engineers reading the actual code.

Look for consistent patterns and conventions. A healthy codebase has a recognizable style. Functions are named clearly. Modules have single responsibilities. There is a logical folder structure. A problematic codebase feels like it was written by 15 different people who never talked to each other, because it probably was.

Check test coverage, but do not obsess over the percentage. 80% test coverage means nothing if the tests are all trivial assertions that never break. Read the tests. Are they testing meaningful business logic? Do they cover edge cases? Can you run the full test suite in under 10 minutes? A test suite that takes 45 minutes to run is a test suite that developers skip.

### 2. Architecture and Scalability

Request or reconstruct an architecture diagram. Identify every service, database, queue, cache layer, and external dependency. Then ask: what happens if traffic doubles overnight? What happens if it 10x's over the next 18 months?

Look for single points of failure. Is there one database handling everything? Is there a monolithic application that will need to be decomposed before it can scale? Are there synchronous calls between services that will create cascading failures under load? These are not hypothetical concerns. They are the exact issues that turn a $5M acquisition into a $5M acquisition plus a $2M replatforming project.

### 3. Security and Compliance

Run **Snyk** or **Dependabot** against all dependencies to identify known vulnerabilities. Check for hardcoded secrets using tools like **TruffleHog** or **GitLeaks**. Review authentication and authorization implementations. Look for SQL injection, XSS, and CSRF vulnerabilities in web applications.

If the target handles sensitive data (PII, financial data, health records), evaluate their compliance posture. Do they have SOC 2 Type II certification? Are they GDPR-compliant? HIPAA? The cost of achieving compliance post-acquisition can be $50,000 to $200,000 and take 6 to 12 months. That needs to be factored into your valuation.

### 4. Infrastructure and DevOps

Evaluate the deployment pipeline. Can the team ship a code change to production in under an hour? Or does deployment require a manual, multi-step process that only one person knows how to execute? Look at deployment frequency. Teams that deploy multiple times per day are in a fundamentally different operational posture than teams that deploy once a month and pray.

Assess cloud costs. Request the last 12 months of AWS, GCP, or Azure bills. Are costs growing linearly with revenue, or is there runaway spending on oversized instances and unused resources? I have seen startups burning $15,000 per month on cloud infrastructure that could be optimized to $4,000 with a week of work. That is $132,000 per year in avoidable spend.

### 5. Team and Knowledge Distribution

This is the pillar most acquirers underweight, and it is arguably the most important. Technology does not maintain itself. You are acquiring people as much as you are acquiring code. Calculate the **bus factor** for critical systems. If one person leaves and a core service becomes unmaintainable, you have a serious problem.

Review the git log. Who is committing code? Is it evenly distributed across the team, or does 80% of the commits come from one or two people? Are there parts of the codebase that only one person has touched in the last year? These are knowledge silos that represent real risk.

### 6. Intellectual Property and Licensing

Verify that the company owns its code. Review IP assignment agreements for every employee and contractor. Check for open-source license violations, especially copyleft licenses (GPL, AGPL) that could force disclosure of proprietary code. Use tools like **FOSSA** or **WhiteSource** to scan for license compliance issues automatically.

## Red Flags That Should Change Your Offer (or Kill the Deal)

Not every finding in a TDD report is a deal-breaker. Technical debt is normal. Legacy code is normal. Imperfect test coverage is normal. But certain findings should make you pause, renegotiate, or walk away entirely.

![Financial analysis spreadsheets highlighting risk factors during acquisition due diligence](https://images.unsplash.com/photo-1554224155-6726b3ff858f?w=800&q=80)

### Critical Red Flags (Consider Walking Away)

- **No version control history.** If the target cannot provide a git repository with meaningful commit history, something is seriously wrong. Either the code was written by contractors who retained ownership, the history was wiped to hide something, or the development process is so immature that you are acquiring a prototype, not a product.

- **Undisclosed open-source license violations.** If the core product is built on AGPL-licensed code and the target has not disclosed this, you may be legally required to open-source the product after acquisition. This is a material misrepresentation that should be addressed in the purchase agreement.

- **Fundamental security architecture flaws.** Storing passwords in plaintext, transmitting sensitive data without encryption, or having no authentication on internal APIs are not bugs. They are symptoms of a development culture that does not take security seriously. Remediation will be expensive and culturally difficult.

- **Single-person dependency on critical systems.** If one engineer is the only person who understands the core platform and that person has no retention agreement in place, you are one resignation away from a crisis.

### Serious Red Flags (Renegotiate the Price)

- **No automated testing.** A product with zero or near-zero test coverage will be expensive to maintain and risky to modify. Budget $100,000 to $300,000 and 3 to 6 months to build a meaningful test suite post-acquisition.

- **Outdated or unsupported dependencies.** If the application runs on Node.js 12, Python 2.7, or Rails 4, you are looking at a significant upgrade project before you can even begin feature development. Plan for 2 to 4 months of dedicated migration work.

- **No CI/CD pipeline.** Manual deployments mean slow iteration, higher error rates, and significant DevOps investment needed. Budget $20,000 to $50,000 to set up a proper pipeline.

- **Excessive cloud spend relative to traffic.** This is not a deal-breaker, but it is a negotiation lever. If the target is spending $20,000 per month on infrastructure for 10,000 monthly active users, their unit economics are broken and you should factor the cost of optimization into your offer.

### Yellow Flags (Note and Plan For)

- **Moderate technical debt.** Every codebase has some debt. The question is whether the team is aware of it and has a plan to address it. If the TDD reveals $200K of tech debt, that is a line item in your integration budget, not a reason to walk away.

- **Documentation gaps.** Most startups have poor documentation. Budget time and resources for knowledge capture during the transition period, especially in the first 90 days post-close when the founding team is still available.

- **Monolithic architecture.** A monolith is not inherently bad. Many successful products run as monoliths. But if your integration plan requires decomposing the monolith into microservices, factor that 6 to 12 month project into your timeline and budget.

## Timelines, Costs, and What to Expect Week by Week

A well-run acquisition TDD follows a predictable timeline. Here is what a typical 3 to 4 week engagement looks like, broken down by phase.

### Week 1: Data Collection and Automated Analysis

The first week is about getting access and running automated tooling. Your TDD team should gain access to all code repositories, the staging environment, cloud infrastructure dashboards, and the project management tool. They will run SonarQube, Snyk, and license scanning tools against the codebase. They will review the architecture documentation (if any exists) and begin mapping the system.

By the end of week 1, you should have quantitative baselines for code quality, security vulnerabilities, test coverage, and dependency health. You should also have a preliminary architecture diagram and a list of questions for the engineering team interviews.

### Week 2: Deep Dive and Engineering Interviews

Week 2 is where the real work happens. Your evaluators are reading code, tracing request flows, stress-testing assumptions about scalability, and sitting down with the target's engineering team. Plan for 4 to 6 hours of structured interviews with the CTO, lead engineers, and DevOps personnel.

The interviews are critical. Ask about the decisions behind the architecture. Ask what they would rebuild if they could start over. Ask about the last three production incidents and how they were resolved. Ask about their hiring plan and who they are worried about losing. These conversations reveal things that no automated scan can detect.

### Week 3: Analysis and Report Drafting

Your TDD team synthesizes findings into a structured report. A good report includes an executive summary (2 pages max), detailed findings organized by pillar, a risk matrix with severity ratings, cost estimates for remediation, and specific recommendations for the integration plan. The report should be written for a business audience, not just engineers. Your CEO and CFO need to understand the implications.

### Week 4: Presentation and Negotiation Support

The final week is about translating technical findings into business decisions. Your TDD team should present findings to the deal team, answer questions, and help quantify the financial impact of each finding. If the TDD reveals material issues, this is when you decide whether to renegotiate the purchase price, add representations and warranties to the purchase agreement, require remediation as a closing condition, or walk away.

In terms of total cost, expect to spend $15,000 to $40,000 for a boutique firm, $40,000 to $80,000 for a mid-tier consultancy, or $75,000 to $200,000 for a Big 4 engagement. The right tier depends on the deal size. For acquisitions under $5M, a boutique firm is usually sufficient. For deals above $20M, the incremental cost of a more thorough evaluation is trivial relative to the risk.

## How to Evaluate the Engineering Team You Are Acquiring

The people side of a technical acquisition is often more important than the code. Software can be rewritten. Institutional knowledge cannot. Here is how to assess the engineering team during your TDD process.

![Engineering team collaborating during a technical review meeting in a modern office](https://images.unsplash.com/photo-1531482615713-2afd69097998?w=800&q=80)

### Quantitative Signals

Start with the data. Pull git log statistics for the last 12 months. Look at commit frequency, code review turnaround times, PR sizes, and contributor distribution. Healthy teams show consistent commit patterns across multiple contributors with reasonable PR sizes (under 400 lines of changes per PR). Unhealthy teams show sporadic, large commits from one or two people with minimal code review.

Check the project management tool. What does sprint velocity look like over the last 6 months? Is it stable, increasing, or declining? A declining velocity trend often signals burnout, attrition, or growing technical debt that is slowing the team down. Look at bug counts and cycle times. How long does it take to go from "bug reported" to "fix deployed"? Teams that can resolve critical bugs within 24 hours are operationally mature. Teams where bugs sit in the backlog for weeks have process problems.

### Qualitative Signals

Interview each senior engineer individually. Ask open-ended questions: What are you most proud of in this codebase? What keeps you up at night? If you had 3 months with no feature pressure, what would you fix? How do you feel about the acquisition?

Pay close attention to the last question. If key engineers are excited about the acquisition and see growth opportunities, your retention risk is lower. If they are anxious, noncommittal, or already interviewing elsewhere, you need to factor attrition into your plan. Replacing a senior engineer who understands the system costs $150,000 to $250,000 in recruiting, onboarding, and lost productivity. Losing two or three can be catastrophic.

For a more comprehensive framework on assessing developer capabilities, see our [guide to evaluating developer work](/blog/how-to-evaluate-developer-work). The same principles apply whether you are hiring an individual contributor or evaluating an entire acquired team.

### Retention Planning

Identify the 3 to 5 most critical engineers and design retention packages before close. The standard approach is a 12 to 24 month retention bonus, typically 25% to 50% of annual compensation, vesting quarterly. This is not optional. It is a core part of the deal economics. If your acquisition model does not budget for retention bonuses, your model is wrong.

## Building Your TDD Playbook: A Repeatable Process for Serial Acquirers

If you are a PE firm, holding company, or corporate development team that acquires multiple companies per year, building a standardized TDD playbook will save you significant time and money on every deal.

### Standardize Your Evaluation Framework

Create a scoring rubric that your TDD team uses on every engagement. Each of the six pillars (code quality, architecture, security, infrastructure, team, IP) should be scored on a consistent scale. We recommend a 1 to 5 rating where 1 means "critical risk, major investment required" and 5 means "best in class, no concerns." This allows you to compare targets across deals and track improvement in portfolio companies over time.

Build a standard checklist for each pillar with 20 to 30 specific evaluation criteria. For example, under security: "Are all API endpoints authenticated? Is data encrypted at rest? Are secrets managed through a vault service? Is there a documented incident response plan?" Having this checklist ensures consistency regardless of which evaluator runs the assessment.

### Invest in Tooling

Maintain a pre-configured toolchain that you can deploy against any target's codebase within hours. Your toolkit should include SonarQube or CodeClimate for code quality, Snyk for dependency vulnerabilities, TruffleHog for secret detection, FOSSA for license compliance, and custom scripts for git log analysis. Automating the first pass saves 3 to 5 days on every engagement.

### Create Integration Playbooks by Archetype

After a few acquisitions, you will notice that targets fall into a handful of archetypes. The "solid product, weak infrastructure" archetype needs DevOps investment but minimal code changes. The "strong team, legacy codebase" archetype needs a gradual migration plan and patience. The "AI/ML product with data moat" archetype needs careful evaluation of data pipelines and model governance. Having pre-built integration plans for each archetype accelerates your post-close execution.

### Track Post-Acquisition Outcomes

The most valuable thing you can do is close the feedback loop. After every acquisition, compare your TDD predictions to actual post-close outcomes. Did the remediation costs match your estimates? Were the red flags accurate? Did the retention plan work? This data makes your TDD process better with every deal. After 5 to 10 acquisitions, your ability to estimate integration costs and timelines will be significantly more accurate than any external firm's.

Whether you are doing your first acquisition or your fiftieth, the principle is the same: invest in understanding the technology before you own it. The cost of a thorough TDD is always a fraction of the cost of a surprise discovered post-close. If you are planning an acquisition and want an experienced team to run the technical evaluation, [book a free strategy call](/get-started) and we will scope the engagement together.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/how-to-run-technical-due-diligence-before-acquisition)*