If your startup is raising, at some point someone like me gets read access to your repo, your cloud account and a call with your lead engineer. I do technical due diligence for investors, and the review is more predictable than founders think. It is not a code style audit. It answers one question: is the technology worth what the deck says, and what will it cost to keep it working?
Here is what I actually look at, and the commands I would run on your repo first.
1. Architecture and scaling
I want to know what breaks at 10x the current load and how expensive the fix is. A monolith is fine. A monolith where every request does a full table scan is not.
What I ask for: a one-page architecture diagram, the three slowest endpoints, and the current peak load. If nobody can draw the diagram, that is the finding.
2. Delivery
How code gets from a laptop to production tells me more than the code itself.
# the 20 most recent release tags with dates, if you tag releases
git tag --sort=-creatordate --format='%(creatordate:short) %(refname:short)' | head -20
# commits in the last 90 days, by author
git shortlog -sn --since="90 days ago" HEAD
I look for CI on every pull request, tests that run, and a rollback that someone has actually done. Weekly or faster deploys are a good sign. "We deploy when Raj is around" is not.
3. Security basics
This is where most fixable red flags live, and you can find them yourself in an afternoon.
# secrets committed anywhere in git history, all branches
gitleaks git -v --log-opts="--all" .
# known vulnerable dependencies across lockfiles
osv-scanner scan source -r .
I also check who has production access, whether it is behind SSO and MFA, and whether customer data is encrypted at rest. If you sell to enterprises, I check how far you are from SOC 2, because the next buyer will ask.
4. Infrastructure cost
I open the cloud bill and divide it by customers. Gross margin problems hide here: a product that costs $40 a month to serve a customer paying $50 is a different company from one that costs $4.
Common findings are idle databases, NAT gateway data charges and logs nobody reads. A cleanup here often improves margin before the round closes, which is worth doing on its own.
5. AI defensibility (if you are an AI company)
The question is what is left if a competitor calls the same model API tomorrow. I look for:
- proprietary data or feedback loops the model gets better from
- an evaluation set and a record of how quality changed between model versions
- cost per request, and what happens to margin if the model price doubles
- how hard it would be to switch model vendor
A thin prompt over a single API is not automatically a red flag, but the deck should not call it a moat.
6. Team and bus factor
# who actually knows the payments code
git shortlog -sn --since="12 months ago" HEAD -- src/payments
If one name owns 90% of a critical directory and that person is a contractor, it goes in the report. Documentation, runbooks and an on-call rotation all reduce this risk.
How findings get graded
Nothing is pass or fail. Each finding gets a grade:
- Green: fine as is.
- Amber: needs work, but the cost is known and fits in the plan. Most findings land here.
- Red: expensive or risky enough to change the valuation or the terms, such as leaked customer data, no backups, or a core system only one departed engineer understood.
Investors expect ambers. What hurts a round is a red the founders did not know about.
A one-week prep list
- Run the commands above and fix what they find.
- Draw the architecture on one page.
- Write down your cloud cost per customer.
- Make sure two people can deploy and roll back.
- Turn on MFA everywhere production lives.
I keep a longer technical due diligence checklist on our blog, and if you are an investor who needs an independent review of an AI or SaaS company, that is the technical due diligence work I do at Axionry.