For a while, “it works” is enough. Then one day it isn’t: you raise a round, take on an enterprise customer, or field an acquisition offer — and someone runs technical due diligence. A neutral engineer opens the hood and reports back to the people with the money. For unreviewed vibe-coded apps, this is where the value quietly leaks out.
It’s worth knowing exactly what they look for, because none of it should be a surprise on the day a deal is on the line.
What a DD reviewer actually checks
- Security posture. Exposed secrets, an open database, auth that’s only enforced in the UI, tenant isolation. One serious finding here reprices the deal — or pauses it.
- Whether it can scale. Naive queries and missing indexes that are fine in the demo and fatal at real load. An investor is buying the future, and the future has more users.
- Maintainability and key-person risk. Can anyone other than the AI extend this? A codebase no human understands is a liability on a balance sheet — see the maintainability trap.
- Tests, CI, and rollback. Can a change ship safely? Or is every deploy a gamble?
- Licensing and dependencies. AI loves to pull in a sprawling dependency tree. DD checks for risky licences and known-vulnerable packages.
- Data and compliance. What personal data you hold, where it flows, and whether that matches your privacy policy.
Why “it works” scores badly here
Due diligence isn’t asking does it run — it’s asking what happens when this is someone else’s problem and someone else’s risk. The green checkmarks that satisfied you tell the reviewer nothing. They’re looking for what breaks, what can’t be changed, and what becomes a legal headache. Unreviewed vibe-coded code is full of exactly those, precisely because the shortcuts that made it fast are invisible until someone reads it adversarially.
Get ahead of it
The founders who sail through DD are the ones who had the same review done before the stakes were high — quietly, on their own timeline, with time to fix what turned up. The worst time to discover three critical issues is mid-deal, with a clock running and lawyers watching.
A production-readiness audit is technical due diligence you commission for yourself, before anyone does it to you: a senior engineer reads your code, finds what a DD reviewer would find, and gives you the prioritised list — with time to fix it while it’s cheap. The best diligence result is the one with no surprises.