Guide · Hiring, contracts & ownership

Technical due diligence checklist for startups: what investors and buyers check, and how to pass

A plain-English technical due diligence checklist for startups: what a code audit covers, what the report should say, red flags, and how to prep in two weeks.

By Akash Bansal, founding engineerUpdated 5 November 20268 min read

Technical due diligence is the part of a funding round or acquisition where someone technical checks that the software is what the pitch deck says it is. For a startup, most of it is not a deep code review. It is a set of plain questions: do you own the code, can a stranger run it, is it secure, will it hold up at ten times the users, and what happens if your one engineer leaves?

This guide is for two readers. Founders who are about to be reviewed, and who want to pass without surprises. And founders or investors about to buy, fund or inherit a codebase, who need to know what to check. I've been on the building side of this for about six years, including five as head of technology at Urban Culture, where we ran four apps (customer, partner, admin console and web) for 500K registered users across six cities. My security habits come from smart-contract auditing, where I had a valid finding in a $63K Code4rena audit. That world assumes the reviewer is looking for the one thing you missed, and it is a useful mindset here too.

What is technical due diligence, and who asks for it?

Technical due diligence is an independent review of a company's software, infrastructure and engineering practice before money or ownership changes hands. Investors usually ask for it at Series A and later; acquirers almost always do. At pre-seed and seed it is often informal: an angel's CTO friend spends an afternoon with your repository.

The reviewer is answering one question for the person paying them: does the technology support the business plan, and what will it cost to fix what doesn't? Everything on the checklist below serves that question.

Is a code audit the same thing?

No. A code audit reads the code for security flaws, quality and maintainability. Technical due diligence includes a code audit but also covers ownership, licences, infrastructure, people and running costs. In my experience the code is rarely what sinks a deal. Ownership gaps and security basics are.

The technical due diligence checklist

Here is what a competent reviewer will look at, grouped by area, with the question each item answers.

1. Ownership and access

• Repositories sit in an organisation the company owns, not in a contractor's or a cofounder's personal account.
• IP assignment is signed by every person and agency who wrote code, including the first freelancer from two years ago.
• Cloud, domain, app store and payment accounts are registered to the company, with at least two named admins and no shared logins.
• Third-party code (templates, paid components, AI-generated code) is covered by its licence for commercial use.

This is the section founders fail most, and it is pure admin. I wrote a separate who-owns-the-code checklist for it.

2. Security

• No secrets (API keys, database passwords) in the repository or its history.
• Authentication and authorisation are enforced on the server, not only hidden in the UI.
• Production data is encrypted at rest and in transit, and backups exist and have been restored at least once.
• Dependencies are patched, and someone gets alerted when a new vulnerability lands.
• Admin access to production is logged, and former staff have been removed.

Leaked secrets are common enough that reviewers search for them first. GitGuardian counted about 29 million new hardcoded secrets pushed to public GitHub in 2025 alone, a 34% rise on the year before (GitGuardian, State of Secrets Sprawl 2026, vendor research). If you've used AI coding tools heavily, look harder: the same report says AI-assisted commits leaked secrets at a higher rate.

3. Open-source licences and dependencies

Almost every codebase is mostly open source, and reviewers check that the licences fit how you sell the product. Black Duck's 2026 report, based on 947 codebases audited during M&A deals, found open source in 98% of them, licence conflicts in 68%, at least one known vulnerability in 87%, and components four or more years out of date in 92% (Black Duck OSSRA 2026, vendor research). Those are deal codebases, not a random sample, but they show what reviewers expect to find. Generate a software bill of materials (a list of every dependency and its licence) before they do.

4. Architecture and scalability

• A one-page diagram of the system that matches what is actually deployed.
• The obvious bottleneck at 10× users has a name and a plan, even if the plan is "add an index and a cache".
• Running costs per user or per transaction are known and don't grow faster than revenue.
• Vendor lock-in is a choice you can explain, not an accident.

Unit cost is where I'd push hardest as a reviewer, because it can quietly break a business model. At Urban Culture, Google's Distance Matrix and geocoding bills grew with every booking. We replaced them with a custom geolocation service that cut that cost by 80% while holding accuracy. A reviewer who spotted the original bill trend would have been right to flag it.

5. Engineering practice

• A new engineer can run the app locally from the README in under a day.
• Deploys are scripted and repeatable (infrastructure as code helps a lot), and there is a way to roll back.
• There are automated tests on the parts that move money or data, even if coverage elsewhere is thin.
• Errors in production reach a human: monitoring, alerting, an on-call habit.

6. People and key-person risk

• How many people understand each critical system? If the answer is one, that is a finding.
• Written design docs exist for the core flows.
• Contractors and agencies have a handover clause and have actually handed over.

7. Claims versus reality

Reviewers compare the deck with the code. "Proprietary AI" that is one prompt to a public model, "real-time" that polls every minute, or "bank-grade security" with no audit logs will all be noticed. None of these is fatal on its own. Being caught overstating is worse than the gap itself, so describe what you built accurately.

What does a good technical due diligence report look like?

A good report ranks findings by business impact and prices the fix. It should contain:

1. A one-page summary a non-technical partner can read: overall view, top three risks, deal-breakers if any.
2. Findings ranked as critical, high, medium or low, each with evidence (a file, a screenshot, a config) and why it matters to the business.
3. An estimate of the time and cost to fix each critical and high finding.
4. A view on whether the architecture and team can deliver the roadmap in the plan.

If you are the one commissioning it, ask for that format up front. Two hundred lint warnings with no ranking is not a report.

Red flags that change a deal

How to prepare for technical due diligence in two weeks

Most of what a reviewer will find, you can find first. Here is the order I'd work in.

1. Days 1–2: ownership. Move repos into a company organisation. Collect signed IP assignments from everyone who wrote code. Check that every account (cloud, domain, stores, payments, email) is in the company's name with two admins.
2. Days 3–4: secrets. Run a secret scanner over the full git history. Rotate anything it finds, even if the repo is private.
3. Day 5: dependencies. Generate a software bill of materials, check licences, and patch the critical vulnerabilities.
4. Days 6–7: run it from scratch. Ask someone who has never seen the code to set it up from the README. Fix every step where they get stuck.
5. Days 8–9: backups and access. Restore a backup into a test environment. Remove former staff. Turn on two-factor login everywhere.
6. Day 10: write it down. A one-page architecture diagram, a list of known debt with your plan for each item, and the unit cost of your main transaction.

Writing down your known debt yourself is the strongest move on this list. A reviewer who finds an issue you already documented, with a plan, marks it as managed. The same issue discovered cold reads as a surprise. If an item on that list says "rewrite", rewrite vs refactor helps you check whether a smaller fix would do.

What if the code was built by an agency or with AI tools?

Then the ownership and security sections deserve extra time, not panic. Agency builds most often fail on account ownership and missing handover. AI-built apps most often fail on server-side authorisation, leaked keys and code nobody can explain. If you're weighing whether to fix such a codebase or start again, I've covered that in rebuild or keep prompting. A reviewer doesn't need the code to be beautiful. They need it to be owned, secure, explainable and runnable.

Who should do the review?

If you are investing in or buying a company, hire someone independent of the deal who has run production systems, not only written code. Ask them for a sample report, a fixed scope in days, and a written list of what they will need access to. A reviewer who has never been paged at 2 a.m. tends to grade style over risk.

If you are the founder being reviewed, you don't need a consultant to pass. You need the two-week list above, done honestly. A friendly pre-review by a senior engineer, such as a fractional CTO, is worth it if you have no technical cofounder, because they will find the embarrassing items in a day. If you're hiring someone for that, my notes on how to vet a developer apply.

On my own builds, the client owns the repositories, cloud accounts and code from day one, gets written design docs, and gets a handover, which covers most of section 1 before anyone asks. If you're preparing for a round and want a senior engineer to look at your product before an investor does, here is how I work.