A founder I worked with last year was two weeks from closing a $2.5M seed round. The lead investor sent over a standard due diligence request. She forwarded it to me with a note: "What do I actually need to worry about here?"
She had been building for 18 months. The product worked. Users liked it. But she had no idea whether her codebase would survive scrutiny from a technical evaluator.
That question - what do they actually look at - is one I have been asked dozens of times. I have been on both sides of this process. I have conducted technical due diligence for investors as an independent evaluator, and I have spent the months before a raise helping CTOs prepare their companies. The same checklist applies in both directions.
Here is what a thorough technical due diligence actually covers.
What Investors Are Really Trying to Assess
Before the checklist, it helps to understand the goal. Investors are not trying to find perfect code. They know most early-stage startups have technical debt. What they are looking for is a specific set of risks:
- Is this codebase maintainable? Can new engineers get up to speed, or is it a maze that only the founder understands?
- Are there hidden liabilities? Security issues, compliance gaps, IP problems?
- Does the technical team actually know what they are doing, or has this been duct-taped together?
- Can this scale to the growth they are about to fund?
A codebase does not have to be clean to pass. It has to be honest and have a clear path forward.
The Architecture Review
The first thing I look at is architecture. Not the slide deck version - the actual system.
I want to understand how the application is structured, how services communicate, and whether the design decisions reflect understanding of the problem or just "what worked quickly." A monolith is not automatically bad. A microservices architecture with six services and two engineers is almost always a liability.
I look for:
- Is there a clear separation of concerns?
- Are the technology choices appropriate for the problem?
- Is there a data model that will scale, or one that will require a painful migration at 50,000 users?
For one due diligence I ran last year, the startup had a Django backend with all business logic in views. It worked, but it meant any change to the product required touching dozens of files. The investor got an honest assessment: the architecture was risky for scale but fixable with 3-4 months of focused refactoring. We put a plan in the report. The deal closed with a technical milestone in the term sheet.
Code Quality Signals
I do not try to read every line of code. That is not possible and not the goal. I look for patterns.
Test coverage. Not a specific percentage - I am looking for whether tests exist and whether they test meaningful behavior. Zero tests with a good explanation is better than 60% coverage on tests that only check that a function was called.
Documentation and comments. Not everywhere, but in the complex parts. If the most business-critical piece of the codebase has no comments, it tells me something about how the team thinks.
Dependency health. I check when dependencies were last updated. A package.json or requirements.txt with 30 outdated packages, including known security vulnerabilities, is a red flag. It suggests nobody is maintaining this system.
Git history. I look at commit messages, branching patterns, and who is committing. A commit history of "fix," "wip," "changes," and "final final" tells me the team is not practicing any engineering discipline. I also look for patterns - are commits clustered in frantic bursts before demos? That can indicate a product that looks better from the outside than it is on the inside.
Security and Compliance
This section kills deals more often than any other.
Secrets in code. I run automated scans and also look manually. Finding AWS credentials in a GitHub repository is an immediate red flag. I have seen this in startup repos more times than I want to admit.
Authentication and authorization. Is user data protected properly? Can user A access user B's data with a simple URL manipulation? For B2B products, this is particularly important - enterprise customers will ask about this in their own diligence.
Data handling. If the product handles sensitive data - health, financial, location - are there appropriate controls? GDPR compliance, if European users are in scope, is increasingly a due diligence item even at seed stage.
HTTPS and encryption at rest. Basic, but I still see violations. If you are storing passwords in plain text in 2025, the conversation changes completely.
Infrastructure and Operations
I ask to see how the application is deployed and how incidents are handled.
Deployment process. Is there CI/CD? Manual deployments that require a specific person to be available are a bus factor problem. If the founder is the only person who can push to production, that is a risk.
Monitoring and alerting. Does anyone know when the application is down before a user reports it? I have evaluated companies where the answer was "we check Slack and wait for complaints." That is not acceptable for a funded company.
Cost structure. Cloud costs relative to revenue. I have seen $40K/month in AWS bills for a product with $8K MRR. The investors need to understand how infrastructure costs will scale with usage.
Backup and recovery. Can you recover from a data loss event? Many early-stage companies cannot answer this question with confidence.
Team Capability Assessment
This is the part that matters most to investors and is hardest to quantify.
I look for evidence that the team has solved hard problems before. Clever solutions to genuinely difficult challenges are a positive signal. I also look for the opposite - complexity where simplicity would work, which suggests inexperience or insecurity.
I talk to the lead engineer directly. I ask about the decisions they are least happy with and why they made them. A good engineer can articulate the tradeoffs clearly. Someone who cannot explain their own decisions is a risk.
I also try to understand knowledge concentration. If one person knows how the payment system works and nobody else does, that is a risk investors will note.
IP and Vendor Risk
Open source licensing. GPL code in a commercial product can be a serious problem. Copyleft licenses are fine for internal tools but can create licensing obligations if you are shipping software. I flag anything that is not MIT, Apache 2.0, or BSD.
Third-party dependencies. If the core product relies on a single third-party API that could change pricing or availability, that is a business risk. Twilio, Stripe, OpenAI - these are all dependencies that could affect the business model.
Ownership. Was any code written by contractors? If so, are there signed agreements assigning IP to the company? This comes up often and is easy to fix if caught early.
What the Report Looks Like
A technical due diligence report is not a list of everything wrong. It is a risk-tiered assessment:
- Critical issues (these must be resolved before close, or at close with escrow)
- Significant issues (these should be addressed in the first 90 days post-funding)
- Minor issues (normal technical debt, no action required immediately)
- Observations (context for the investor, not actionable items)
Most seed-stage companies have zero critical issues, a handful of significant ones, and a long list of minor issues and observations. That is normal. The goal is an honest picture, not a perfect score.
How to Prepare Your Company
If you know a diligence is coming, there are five things worth doing immediately.
First, scan for secrets in your repository. Use tools like git-secrets or TruffleHog. Fix anything that comes up.
Second, document your deployment process. Even a one-page runbook showing how to deploy and how to roll back is better than "ask Marcus."
Third, make a list of your major architectural decisions and why you made them. You will be asked. Having clear answers shows technical maturity.
Fourth, check your open source license inventory. One afternoon with a spreadsheet will tell you if you have a GPL problem.
Fifth, update your critical dependencies. Not all of them - that takes too long. But any package with a known CVE should be patched before someone else finds it.
I worked with a fintech startup last year that had 90 days before their Series A diligence. We spent six weeks on targeted preparation - secrets scan, infrastructure documentation, architectural decision records, a basic test suite on the payment flows. The diligence came back clean on critical items. They closed without any technical conditions in the term sheet.
Preparation does not mean hiding problems. It means understanding your own system well enough to explain the problems and their mitigations honestly. That is what investors are actually assessing - not perfection, but clarity.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr