Passing technical due diligence: what investors actually check

Technical due diligence surprises founders. They have rehearsed the vision, the market size and the unit economics, and then receive a questionnaire about deployment pipelines and single points of failure.

The questions are not designed to find a perfect codebase. Investors know early-stage systems are rough. They are trying to establish three things: whether the technology can support the growth being projected, whether the team understands what they have built, and whether there is a hidden liability that will consume the investment.

Code quality and maintainability

Expect a review of the repository, often by a technical adviser rather than the investor directly. They are looking for:

• is there version control discipline — meaningful commits, branches, reviewed merges
• can a new developer understand the structure from reading it
• are there tests, and do they cover the parts that would be expensive to break
• is there obvious accumulation of shortcuts that will need unwinding
• how much depends on one person's undocumented knowledge

A scrappy codebase with clear structure and honest tests reads far better than an elaborate one nobody can explain.

Prepare a short architecture document: the main components, how they communicate, what is hosted where, and which decisions you would make differently now. That last section signals maturity more than anything else you can write.

Infrastructure and operations

Common questions:

• where is it hosted, what does it cost monthly, and how does cost scale with users
• is deployment automated or manual, and how often do you deploy
• what monitoring exists, and how would you know about an outage before customers told you
• what happens if the primary database fails
• what is your uptime over the last six months, measured rather than estimated
• who has production access, and is it logged

If deployment is manual and you have no monitoring, say so and describe the plan. Investors fund remediation. They do not fund the discovery that you were unaware of the gap.

Security and data protection

This is where early-stage ventures most often have real exposure.

Expect questions about:

• authentication, session handling and password storage
• encryption in transit and at rest
• access control between customers, especially in multi-tenant systems
• what personal data you hold, where it is stored, and your lawful basis
• whether you have had a security incident, and what you did about it
• third-party processors and what data they can see
• backups and whether a restore has ever been tested

If you hold health, financial or children's data, the scrutiny increases substantially and compliance evidence becomes a condition of investment rather than a nice-to-have.

Answer honestly. A disclosed weakness with a remediation plan is a manageable finding. A weakness discovered by the adviser that you did not mention is a trust problem.

Intellectual property

• does the company own the code, and is every contributor under a written agreement assigning it
• are there contractors or former co-founders without assignment paperwork
• what open-source licences are in use, and are any of them copyleft in a way that affects distribution
• are there any third-party components whose licence would be violated by your commercial model

The contractor-without-assignment problem is extremely common and extremely fixable before diligence starts. Fixing it during diligence, under time pressure, is a different experience.

Run a licence scan before you raise. Most permissive licences are unremarkable; one copyleft component in a distributed product can require legal work you did not budget for.

Team capability and key-person risk

Investors want to know what happens if your only engineer leaves next month.

Honest answers include documentation, deployment scripts, a codebase that can be picked up, and a realistic view of how long hiring would take in your market.

If the honest answer is "the product stops", that is a finding you should address before raising rather than defend during diligence. It also strengthens your argument for using part of the investment on a second engineer.

Technical scalability of the projections

Your model probably shows significant user growth. Expect the question: what breaks first?

Have a considered answer. Usually it is one of: database query performance, a synchronous third-party API call, file storage, a manual operational process that does not scale with users, or support volume.

Naming the constraint and describing the plan to address it demonstrates exactly the engineering judgement investors are assessing. Claiming nothing breaks suggests you have not looked.

What to prepare before you raise

A diligence pack assembled in advance shortens the process considerably:

1. Architecture overview with a diagram and honest notes on technical debt
2. Repository access instructions and a guide to the codebase structure
3. Infrastructure inventory: hosts, services, monthly costs, scaling behaviour
4. Deployment and monitoring description, including incident history
5. Security posture summary and any assessments or scans completed
6. Data inventory: what personal data, where, lawful basis, retention
7. IP position: contributor agreements, contractor assignments, licence scan results
8. Team structure and key-person risk assessment
9. Known issues list with severity and remediation plan
10. Cost and capacity projection against your modelled growth

Item nine is the one founders resist including and the one that builds most credibility. A founder who can enumerate their own weaknesses is a founder who is looking properly.

The meta-point

Due diligence is not a test you pass by having built something perfect. It is a test of whether you understand what you have built.

Founders who know their system's weaknesses, have plans for them and can explain their trade-offs raise more easily than founders with better technology and less self-awareness. Prepare the understanding, and the paperwork follows.