Technical due diligence checklist: what investors and acquirers check, and how founders prepare

Technical due diligence is an independent review of a company's software, infrastructure and engineering team, carried out before someone invests in it, buys it or signs a large contract that depends on it. The reviewer reads the code, the architecture, the security set-up, the cloud bills and the delivery history, interviews the people who built it, and writes a report that says what is sound, what is risky and what it will cost to fix. It answers three questions for the buyer: does the technology do what the company says, will it hold up at the next stage of growth, and what is hiding in it that changes the price or the plan. Below is a copyable checklist in nine areas, a red and amber flag table, what the report should contain, and how a founder can prepare.

When it happens

Technical due diligence usually sits between a term sheet or letter of intent and closing, once the commercial case is agreed and the buyer wants to confirm what they are paying for. It also happens earlier, as a lighter screen before a term sheet, and in other situations:

• Venture rounds, from seed to growth, at a depth that rises with the size of the cheque.
• Acquisitions and carve-outs, where the buyer has to run or integrate the system after closing.
• Large customer or partner contracts, where a buyer's security or architecture review decides whether the deal goes ahead.
• Inherited systems, when a new CEO, CTO or board wants an honest read of what they now own.
• Before a raise, when founders run it on themselves so nothing surprises them in the real one.

Scope by deal type

The checklist below is the full set. How much of it a reviewer covers depends on the deal. This table is how we scope it; other firms draw the lines differently.

The technical due diligence checklist

Copy the sections that apply. Each item is a question for the company and the evidence to ask for. Mark each one green, amber or red as you go.

1. Architecture

• System overview. What are the main components, how do they talk to each other, and where does data live? Evidence: a current architecture diagram, checked against the code and the cloud console.
• Data model. Is the core data model coherent, with clear ownership of each entity? Evidence: schema, migrations history, entity diagram.
• Multi-tenancy. How is one customer's data kept from another's? Evidence: the code path that enforces it, and tests that prove it.
• Integrations. Which third-party systems does the product depend on, and what happens when each is down? Evidence: list of integrations, error handling, status-page history.
• Single points of failure. Which component, vendor or person, if lost, stops the product? Evidence: interviews, hosting set-up.
• Decision records. Are big technical decisions written down with the reasons? Evidence: architecture decision records or design docs.
• Fit for the plan. Does the architecture support the next 18 months of the roadmap without a rewrite? Evidence: roadmap compared with the design.

2. Code quality and maintainability

• Readability. Could a competent new engineer find their way around in a week? Evidence: a code read of the two or three most important services.
• Tests. What is covered by automated tests, and do they run on every change? Evidence: CI configuration and recent runs, coverage report for core logic. Coverage percentage alone says little; read what the tests check.
• Static analysis. Are linting, type checking and dependency scanning in the pipeline? Evidence: CI configuration.
• Code review. Does every change get reviewed before merge? Evidence: pull request history and branch protection settings.
• Dependencies. How out of date are frameworks and libraries, and are any end of life? Evidence: dependency manifests and an audit report.
• Dead and duplicated code. How much of the codebase is unused or copied? Evidence: tooling output and a sample read.
• Technical debt register. Does the team know where its debt is, and is any of it scheduled? Evidence: backlog items, the team's own list.
• AI-generated code. How much was written with AI coding tools, and was it reviewed like any other code? Evidence: interviews, review history. For apps built mostly with Lovable, Bolt, Replit, Cursor or Claude Code, run our AI-built app security checklist as well.

3. AI, models and data rights

• Inventory. Which models, from which providers, are used where, and through which accounts? Evidence: the code paths that call models, provider invoices.
• Provider terms. Do the provider contracts allow the use the company makes, and do they say whether inputs are used for training and how long they are kept? Evidence: the signed terms and the account's data settings. Read the contract; do not rely on a summary.
• Training data rights. Where any model was trained or fine-tuned, where did the data come from, and did the company have the right to use it that way, including customer data under customer contracts? Evidence: data sources, licences, customer agreements.
• Ownership of outputs and weights. Who owns fine-tuned weights, prompts, evaluation sets and generated content? Evidence: contracts with providers, contractors and customers.
• Evaluations. Is model quality measured against a fixed test set before each release? Evidence: the eval set, recent results, the release gate.
• Security. Has the system been tested for the risks in the OWASP Top 10 for LLM Applications 2025, especially prompt injection (LLM01), sensitive information disclosure (LLM02), excessive agency (LLM06) and unbounded consumption (LLM10)? Evidence: test reports, guardrails in code, spending limits.
• Cost and dependence. What does each model call cost, what is the monthly bill, and how hard would it be to switch provider if prices or terms changed? Evidence: invoices, the abstraction layer in code.
• Regulation. Does any feature fall under rules that apply to AI, such as the EU AI Act? Evidence: the company's own assessment. Our AI policy template summarises the AI Act's dates; whether a system is in scope is a question for counsel.

4. Security

• Authentication and access. How do users and staff sign in, and is multi-factor authentication enforced for staff and admin access? Evidence: identity provider settings.
• Secrets. Are keys and passwords in a secrets manager, and have any ever been committed to the repository? Evidence: a secrets scan across the full git history, not just the latest commit.
• Application security. Has the application been tested against a recognised standard? Evidence: penetration test reports and fixes. The OWASP Application Security Verification Standard (version 5.0.0, May 2025) is a common reference.
• Vulnerability management. How fast are critical vulnerabilities in dependencies and infrastructure fixed? Evidence: scanner output and ticket history.
• Data protection. Is personal and sensitive data encrypted in transit and at rest, minimised, and deletable on request? Evidence: configuration, data map, deletion procedure.
• Logging and detection. Would the team know if someone accessed data they should not? Evidence: audit logs, alerting rules.
• Incidents. Have there been security incidents or breaches, and how were they handled and disclosed? Evidence: incident log, post-mortems, any notifications to customers or regulators.
• Compliance evidence. If the company claims SOC 2, ISO/IEC 27001, HIPAA or similar, is the claim current and does its scope cover the product? Evidence: the report or certificate, with its scope and dates.
• Staff offboarding. Is access removed when people leave? Evidence: the offboarding checklist and a sample of recent leavers.

5. Infrastructure, reliability and cost

• Hosting. Where does it run, under whose account, and is everything defined as code? Evidence: cloud account ownership, infrastructure-as-code repository.
• Environments. Are development, staging and production separate, with production data kept out of development? Evidence: environment list, access rules.
• Backups and recovery. Are backups automated, stored separately and restored in a test at least once? Evidence: backup configuration and the last restore test.
• Uptime and incidents. What has availability been over the last 12 months, and what caused the outages? Evidence: monitoring data, status page, post-mortems.
• Monitoring. Are errors, latency and saturation monitored with alerts to a named person? Evidence: dashboards, on-call rota.
• Cloud cost. What is the monthly bill, how does it split by service, and what is the cost per customer or per transaction? Evidence: 12 months of invoices and cost explorer exports.
• Vendor contracts. Which hosting and SaaS contracts are committed, for how long, and are they in the company's name? Evidence: contracts, renewal dates.
• Disaster recovery. If the main region or provider failed, how long to recover and how much data lost? Evidence: the written plan and the last test.

6. Team and process

• People. Who built what, who still works there, and which knowledge sits with one person? Evidence: org chart, interviews, commit history by author.
• Contractors and agencies. How much was built by outsiders, are they still involved, and do they hold access? Evidence: contracts, access lists.
• Delivery metrics. How often does the team deploy, how long does a change take to reach production, and how often do releases fail? DORA now uses five measures: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Evidence: CI/CD history. DORA warns against comparing very different teams or applications, so judge the trend, not a league table.
• Planning. How is work chosen, estimated and tracked? Evidence: the backlog, the last few sprints or cycles.
• On-call and support. Who responds to incidents out of hours, and how are customer bugs handled? Evidence: on-call rota, support queue.
• Hiring. Can the company hire the engineers the plan needs, at the salaries in the model? Evidence: open roles, recent hires, time to fill.
• Documentation. Is there enough written down for a new team to run the system? Evidence: runbooks, onboarding docs.

7. IP and open-source licences

• Ownership. Has every employee and contractor who wrote code assigned their IP to the company? Evidence: signed agreements for everyone in the commit history, including early contractors and founders' previous companies.
• Third-party code. Is any code copied from other projects, previous employers or the internet without a licence? Evidence: a code provenance scan.
• Open-source inventory. Which open-source components are used, under which licences? Evidence: a software bill of materials, which CISA describes as a nested inventory of the components that make up software.
• Copyleft exposure. Is any GPL or AGPL code linked into proprietary code that is distributed or offered as a service? Section 13 of the GNU AGPL v3 requires a modified version to offer its source to users who interact with it over a network, which matters for SaaS. Evidence: the SBOM filtered by licence, and how each component is used. Have counsel interpret any finding.
• Licence compliance. Are attribution and notice requirements met in the shipped product? Evidence: the notices file or about screen.
• Patents and trademarks. Are there registered or pending patents, and any claims against the company? Evidence: filings, correspondence.
• Escrow and licences out. Has source code been placed in escrow or licensed to a customer? Evidence: customer contracts.

8. Scalability and performance

• Current load. What are today's users, requests, data volume and peak traffic? Evidence: monitoring data.
• Headroom. What happens at five or ten times today's load? Evidence: load test results, or a reasoned estimate from the architecture.
• Bottlenecks. Which component fails first: the database, a queue, a third-party API rate limit, a single server? Evidence: profiling, query analysis, limits of each provider.
• Database. Are indexes, query patterns and growth under control, and is there a plan for when one database is not enough? Evidence: slow query log, table sizes, growth rate.
• Cost at scale. Does infrastructure and AI cost grow slower than revenue, or faster? Evidence: cost per customer over time.
• Performance for users. How fast are the main pages and API calls at the 95th percentile? Evidence: real user monitoring or APM data.

9. Product delivery

• Roadmap against history. Has the team shipped what it said it would over the last two or three quarters? Evidence: past roadmaps compared with release notes.
• Demo against reality. Does every feature shown in the pitch exist in production, and which are manual behind the scenes? Evidence: a walk-through of production with an engineer, not a demo environment.
• Release process. How does a change reach customers, and can it be rolled back? Evidence: deploy pipeline, feature flags, rollback history.
• Quality. What is the bug backlog, and how many customer-reported bugs arrive each month? Evidence: issue tracker.
• Product analytics. Can the company show which features are used? Evidence: analytics dashboards.
• Roadmap risk. Which planned items need a rewrite, a new hire or a capability the team has not built before? Evidence: interviews, the roadmap.

The document request list

Send this to the company on day one, so the review does not sit waiting for access.

1. Read-only access to the source repositories, including history.
2. Read-only access to the cloud accounts, CI/CD and monitoring.
3. Architecture diagrams and any design documents.
4. The last 12 months of cloud and AI provider invoices.
5. Penetration test reports, security policies and compliance reports or certificates.
6. Incident and post-mortem log for the last 12 months.
7. List of employees and contractors who have written code, with IP assignment agreements.
8. Software bill of materials, or permission to generate one.
9. Contracts with hosting providers, AI providers and key SaaS vendors.
10. Product roadmap for the last and next 12 months.
11. Org chart and engineering hiring plan.
12. Interview slots with the CTO or technical lead and two engineers.

Red flags and amber flags

A red flag changes the price, the structure or the decision. An amber flag goes into the post-closing plan with a cost and an owner. The same finding can be either, depending on the deal.

What the report should contain

A useful report is short enough for the investment committee to read and specific enough for an engineer to act on.

1. Executive summary. One page: the overall verdict, the red flags, and the estimated cost and time to fix them.
2. Scope and method. What was reviewed, what access was given, who was interviewed, and what was out of scope.
3. Findings by area. The nine areas above, each finding rated by severity with the evidence behind it.
4. Red flags in detail. What was found, why it matters to this deal, and the options.
5. Remediation plan. Each fix with an owner, an estimated cost and a timeframe, split into before closing, first 100 days and later.
6. Strengths. What was done well. Buyers need this to judge the team, and founders deserve to see it.
7. Appendix. Architecture diagram as found, SBOM summary, metrics collected, interview list.

How long it takes

It depends on the size of the codebase, the depth the deal needs and how quickly access arrives, so we quote technical due diligence as a fixed price after a short scoping call. A narrower review of one AI-built app is our Prototype Production Review, which takes 5 business days. The review cannot start until repository access, contracts and interview slots arrive, which is why the request list above goes out on day one.

How to prepare as a founder

You will be judged on how you handle the findings as much as on the findings themselves. Six weeks before a raise or a sale:

1. Run the checklist on yourself. Mark every item honestly. Fix the cheap reds and write down the plan for the rest.
2. Close the IP gaps. Find everyone in the commit history and get signed assignments from anyone missing.
3. Generate an SBOM and review the licences. Replace or isolate anything you cannot comply with.
4. Rotate secrets and scan the full git history. Assume the reviewer will run the same scan.
5. Restore a backup into a clean environment and write down how long it took.
6. Update the architecture diagram so it matches production, and write a one-page note on the decisions you would make differently and why.
7. Collect the evidence: 12 months of invoices, the incident log, pen test reports, the roadmap against what shipped.
8. Set up read-only, time-limited access for reviewers, ready to grant on the day the NDA is signed.
9. Brief your team. Engineers will be interviewed. They should answer plainly, including about known problems.

Do not hide known problems. A reviewer who finds something you knew about and did not mention will question everything else.

Where Gigabit fits

Our fractional CTO and technical due diligence service runs this review for investors, acquirers and companies taking on a major contract, and for founders who want to run it on themselves first. A senior engineer reads the code, systems and documents, interviews the people who run them, and writes a report with severity-ranked findings and a costed plan. We sign an NDA before any code is shared, and reviews run on read-only, time-limited access. Full due diligence is a fixed price after scoping. For a single app built with Lovable, Bolt, Replit, Cursor or Claude Code, the Prototype Production Review is $2,500 fixed over 5 business days. If the AI features themselves need red-teaming for prompt injection and data leakage, the AI Security Assessment starts at $12,000 fixed; our guide to what an AI security assessment covers explains the scope. When the report finds work to do, the same team can do it on an embedded basis at $3,000–$7,500 per engineer per month.

We have also been on the other side. For the logistics SaaS MVP we built, the founder closed a $2.1M Series A four months after launch, and the lead investor audited the codebase. In the founder's words: "My Series A investors audited the codebase. They said it was cleaner than most Series B companies they'd seen." It shipped with 78% automated test coverage.