Technical due diligence: what investors look at in your app

In a technical due diligence review, investors check whether the company really owns its code, whether the product is secure, whether it can grow without a rewrite and whether the team can keep shipping. They look at the code, the infrastructure and the people, and they're looking for risks that would change the price or the deal, not for perfect code.

This guide explains what's usually reviewed at each stage, the questions you'll be asked, the red flags that matter most for apps built with AI tools and how to prepare in the weeks before.

When does technical due diligence happen?

It depends on the round and the investor. At pre-seed and seed, it's often a conversation with a technical partner or advisor, a demo and a look at the repository. At later rounds, or in an acquisition, it can be a formal review by an outside firm with access to the code, documentation and the team.

Either way, the questions are similar. The depth changes.

What do investors look at?

Ownership of the code

• Does the company own the repository, or is it in a founder's or contractor's personal account?
• Has everyone who wrote code (co-founders, employees, freelancers, agencies) signed an agreement assigning it to the company?
• Which third-party and open-source components are used, and under which licences?

For apps built with AI tools, expect a question about how much of the code was generated and how it was reviewed. Our plain-words overview of who owns AI-made code covers the background. Ownership is a legal question as much as a technical one, so have a lawyer review your agreements; this guide isn't legal advice.

Security

• Are secrets kept out of the code and the frontend?
• Is access to data enforced on the server, so one customer can't read another's?
• Is personal data handled in a way that matches the privacy policy and the laws that apply?
• Has there been a security incident, and how was it handled?

Reviewers often use a recognised list such as the OWASP Top 10 as a reference. See our guide on the OWASP Top 10 for AI-built apps.

Architecture and scalability

• Can the system handle the growth in the business plan without being rebuilt?
• Are there obvious bottlenecks: a single server, slow queries, a third-party API with tight limits?
• How dependent is the product on a single vendor, and how hard would it be to move?

Code quality and process

• Is the code in version control with a readable history?
• Are there automated tests for the critical paths?
• How does code get to production, and can a bad release be rolled back?
• How much technical debt is there, and is it known and tracked?

Team and knowledge

• Who understands the system, and what happens if that person leaves?
• Is there documentation a new engineer could use?
• What does the hiring plan for engineering look like, and is it realistic?

Costs

• What does the infrastructure cost now, and how will that grow with users?
• Are there large or unusual costs, such as AI model usage, that grow faster than revenue?

What red flags come up in AI-built apps?

These are the issues that tend to change a conversation with an investor:

1. Code or accounts in personal names. The domain, the database or the repository belong to a founder's personal account or a freelancer.
2. Missing data protection. Database tables without access policies, or permissions checked only in the browser.
3. Secrets in the frontend. API keys for paid services or admin access visible in the shipped code.
4. No separation between test and production. Real customer data mixed with experiments.
5. Nobody can explain the code. The app was built by prompting, and no one on the team can say how a given feature works.
6. No path off the builder. The product can't run outside the tool it was built with.

None of these is necessarily a deal-breaker on its own. What matters is that you know about them and have a plan.

How should you prepare?

Start a few weeks before you expect questions:

1. Consolidate ownership. Move the repository, domain and service accounts into the company's name, and collect signed assignments from everyone who contributed.
2. Get your own review first. An independent code and security review lets you fix the worst issues, or at least describe them, before an investor finds them.
3. Fix the critical items. Exposed keys, missing database policies and missing backups are usually quick to fix and look bad if left.
4. Write the overview. A short architecture document, a list of services and their costs, and how deployment works. See documenting your app for handoff.
5. Prepare a data room folder. Architecture overview, list of dependencies and licences, security measures, incident history, infrastructure costs and the engineering roadmap.
6. Be honest about debt. A clear list of known problems and a plan to address them inspires more confidence than a claim that there are none.

Quick answers

Do seed investors really look at the code? Some do, some don't. Many at least ask who built it, who owns it and what it runs on.

Will using AI tools hurt my valuation? Using AI tools isn't a problem in itself. Code nobody understands, security gaps and unclear ownership are.

Should I get my own technical review before fundraising? It's usually worth it, because you can fix the issues on your schedule rather than during the deal.

What documents should I have ready? An architecture overview, a list of services and costs, IP assignment agreements, open-source licence information and a security summary.

Getting ready to raise?

Our App Rescue Audit ($299) is a senior engineer's review of your code with a written report in 2 business days, a useful starting point before investors look. You can begin with the free App Health Check, and if the review turns up work, we can help through maintenance and support or MVP development. Contact us to talk it through.