TL;DR: Investors now run a security check before they sign. Two findings show up most. One: a live API key sitting in your public code. Two: a Supabase table anyone can read. Both are fast to find. Both are fast to fix. Fix them before your data room opens. Do not wait for a reviewer to flag them. Start with a free scan to see where you stand today.
Key Takeaways
- Technical checks now run next to legal checks. A reviewer opens your code the same week a lawyer opens your cap table.
- Exposed secrets are the top finding. A live key gets typed into a config file during a fast build. It never gets removed.
- A weak Supabase policy is the second most common finding. One open table lets the public key read every row.
- One-third of deals collapse at the final step. The cause is often a gap a founder could have fixed early (Evalyze, 2026).
- Docs debt shows up in about 90% of technical reviews (Made With Love, 2026).
- Neither fix needs a rewrite. Secret rotation and RLS policy work take a day or two, most of the time.
What a Reviewer Actually Checks Before You Raise
Old-style due diligence meant a slow code review. It came weeks after the term sheet. That is gone now.
Today's reviewer runs a short list of checks. Many test your live product first. They rarely wait for repo access.
The list covers login rules, exposed secrets, and database access. It also covers weak dependencies and privacy paperwork. It does not care how fast you shipped. It asks one question per line: pass, or fail.
Nobody gets credit for speed. A reviewer will not care that you used Cursor. A reviewer will not care that you used Claude Code to move fast, either. Each check is a yes or a no.
Why AI-Built Apps Fail This Check So Often
AI coding tools are great at shipping a feature. They are not built to ask who else can reach that feature.
Ask Cursor, Bolt, or Lovable to build a dashboard. It builds one that works for the person logged in. It does not stop a second user. That user could pull someone else's data through the same call. Not unless you ask for that, too.
The demo works. Signup works. The dashboard loads. One rule is often missing. It is the rule that keeps user A out of user B's data. Another rule is often missing too. It is the one that keeps your API key off the public bundle.
We call this the gap. It is the space between "the demo works" and "this is ready to launch." Most findings in a codebase security audit sit inside that gap.
A reviewer is not testing your product idea. A reviewer is testing whether your team understands what it built. That single question shapes how hard they look at the rest of your data room.
Exposed Secrets: The Risk Hiding in Your Git History
Secrets end up in three spots. Founders rarely check any of them. Spot one: the public JavaScript file sent to every visitor. Spot two: an old commit that was "fixed" later but never wiped clean. Spot three: an environment file, committed by mistake, before anyone set up a .gitignore rule.
AI tools make this worse in one clear way. Ask an assistant to "connect Stripe." It often writes the key straight into a config file. That is the fastest path to a working demo.
The key works. Nobody notices. The app runs fine in the browser.
Then a reviewer opens dev tools. Or a reviewer runs a basic scan. Either way, they find a live key sitting in plain text. Anyone can copy it. This is not a guess. It is a real string of characters. A reviewer can paste it straight into a terminal.
The fix is simple, not architectural. Rotate every exposed key. Move secrets into environment variables. Those never reach the browser. Add a secret scanner to your commit step. Rewrite git history if a key was ever pushed live. None of this touches your product roadmap. All of it should happen before your data room opens.
Supabase RLS: When the Public Key Reads Everything
Supabase is the default backend for most AI-built apps today. Its security model is good on paper. Row-level security runs inside the database itself. Even a public key can only see what a policy allows.
Here is the catch. RLS is off by default on a new table. AI tools skip turning it on, often. A locked table breaks the demo they are trying to finish fast.
So the tool leaves RLS off. Or it turns RLS on. Then it writes a policy like USING (true), just to stop the errors. That one line defeats the whole point. At a glance, it still looks set up correctly.
Here is the result. Your public key sits in your browser bundle. That same key can read every row in every table. This is one of the first things a reviewer tests. One request, using your anon key, with no user filter. That single request tells them everything.
Our own scanner reads your public bundle. It looks for a live Supabase URL and its anon key (scanner.js:100). Say a founder allows a deeper check. We then query that key against the live database. We flag every table it can read. Each one is a critical finding. Each sits in the same risk class as CVE-2025-48757 (scanner.js:323). Our secrets scanner treats any live key found in a public file as critical. Age does not matter (gitleaksScanner.js:4). We have scanned many SaaS apps, websites, and apps. The average Launch Readiness Score sits at 42 out of 100.
Fixing RLS means writing one policy per table. Every policy checks one thing. Does this row belong to the person asking for it? That is not exciting work. It is exactly the work an AI tool will skip, unless someone checks for it. Our guide to the Supabase anon key vs. the service-role key walks through this step by step. So does our free RLS checker.
The Cap Table Security Audit Now Includes Your Codebase
"Cap table security audit" used to mean one thing. Clean option grants. No phantom shares. No side letter nobody remembers signing. That part is still legal work, not technical work.
But the phrase means more in 2026. The same data room holds your cap table. It now holds your tech notes too. It holds your security posture too. Reviewers move between both in the same sitting.
A messy cap table raises a governance question. A leaking Supabase table raises a different question. Does this team understand its own product? Both questions chip away at trust. That thing is confidence. Confidence that the company holds up once the check clears.
This is why we treat pre-raise prep as one job, not two. Clean your equity records and your codebase in the same sprint. A reviewer who finds a problem in one column starts looking harder at the other.
The Pre-Fundraising Security Checklist
Here is the list we use. It is the same list we would hand any founder. That founder is heading into a raise in the next 90 days.
| Check | What a Reviewer Looks For | Common Gap in AI-Built Apps |
|---|---|---|
| Exposed secrets | Live keys in public bundles or old commits | Keys typed in fast, never rotated out |
| Supabase RLS | A policy on every table, scoped by owner | RLS off, or a policy that lets the public key read everything |
| Auth and sessions | Tokens expire; role checks run on the server | Role checks only in the browser, easy to bypass |
| Security headers | CSP, HSTS, and X-Frame-Options are present | Default deploy ships with none of them set |
| Dependency health | No known critical bugs in production packages | Packages pinned at whatever version the tool picked |
| Privacy paperwork | A lawful basis, a retention rule, an AI notice if needed | No privacy layer built, no AI disclosure written |
| Cap table hygiene | Clean grants, no undocumented side letters | Legal work, checked with counsel before the raise |
GDPR and the EU AI Act: The Other Line Item in the Data Room
Did you build your product with Lovable, Bolt, Cursor, or v0? Your privacy setup is likely incomplete. That is common, not rare. Not because you cut a corner. Because the tool never wired that layer in.
A lawful reason to hold user data. A retention rule. A working way to delete a user's data on request. None of this shows up unless someone builds it. "Build me a signup form" does not include it.
The EU AI Act adds one more line. Article 50 says you must tell users when they talk to an AI system. That includes a chatbot. It includes AI-written content too. This rule starts on August 2, 2026.
This rule sits in a lower fine tier. Compare it to the Act's rules on banned AI uses. A transparency miss can cost up to €15 million. Or it can cost 3% of yearly global revenue. A banned practice can cost up to €35 million, or 7%. Founders often mix these two up. A reviewer checking your Article 50 status will not.
None of this needs a lawyer on retainer, not at a basic level. Our GDPR and EU AI Act check runs 60 tests. Each test runs against your live product. It hands back a Compliance Score with a fix list. The whole thing takes under three minutes. No code access needed.
Fix Both Issues Before Your Data Room Opens
Most security tools are built for a large company with its own security team. Hiring an engineer takes weeks you may not have. Doing nothing costs the most of all. A finding found during diligence can stall your whole round. It can reprice it too. That is a much bigger cost than one bug ticket.
A compliance certificate is not proof your Supabase policies are correct. A check built for AI-built apps already knows the default gaps. It knows the gaps in Lovable, Bolt, Cursor, and Supabase. A generic scanner does not know those gaps. That is why it catches less.
We built the Launch Readiness Audit around this exact gap. A free scan gives you a baseline score first. It checks your live URL. No code access needed. The full Launch Readiness Audit is a $499 one-time report. It covers the four areas a reviewer checks most. Those areas are exposed secrets, database access, login handling, and dependency health. Want ongoing coverage instead of one report? Our Pro plan runs $599 a month. It scans your product daily. A new gap will not sit undiscovered for months.
What to Expect From an Audit Run Before You Raise
A proper audit follows a simple shape. Run it before the raise, not after a reviewer flags something.
First, a scan of the live product. It checks for secrets in the bundle, open endpoints, and missing headers. It runs RLS checks against Supabase, or whatever database you use. Second, a fix list. It is ranked by what a reviewer checks first. It is not a random list of every issue we found.
Third, a re-check once the fixes ship. This is the step most fast-built apps skip. A fix nobody verified is a claim. It is not a result yet. Our guide to finding exposed secrets walks through this step. So does our plain answer on Supabase safety.
Want your data room ready before you even start writing it? Our guide to the security questionnaire investors send covers what shows up next. Our guide to screening AI-generated code before it ships shows how to catch these gaps early. Catch them before a reviewer ever sees them.
Run a Free Scan Before Your Data Room Opens
The fastest way to know where you stand? Run the check yourself. Test your own live product. Do it before anyone else does.
Our free security scan runs against your live URL. No code access needed. It returns a baseline read on exposed secrets, RLS gaps, and the rest of this checklist. Get that read before your data room goes anywhere near an investor.
See where your fundraising security risk sits
The free scan reads your live URL from the outside. It checks DNS, page source, public files, and platform fingerprint. You get a Launch Readiness Score out of 100 in about 30 seconds. No signup. No code access. No sales call.
Run the free scan — $0FAQ
What does technical due diligence check for at an early-stage startup?
It usually covers exposed secrets in public code or old commits. It covers database access rules, such as Supabase RLS. It covers login and session handling. It covers dependency bugs, and privacy paperwork like GDPR and the EU AI Act. Reviewers often test your live product directly. They do not just read your code.
Why do AI-built apps fail this check more than hand-built ones?
Tools like Cursor, Lovable, Bolt.new, and v0 build for a working demo. They do not build for who else can reach an endpoint. Access rules are rarely part of the prompt a founder gives the tool. Secret storage is rarely part of it too. So both gaps show up often.
What is Supabase RLS, and why does a reviewer care about it?
Row-level security is a database rule. Supabase uses this rule to limit which rows a request can see. Even the public key is limited by it. Say RLS is off. Or say a policy is written as USING (true). Either way, that public key can read every row in the table. This is one of the first things a reviewer tests.
How much does a codebase security audit cost before a raise?
A full Launch Readiness Audit is a $499 one-time report. It covers exposed secrets, database access, login handling, and dependency health. Ongoing coverage with daily scans runs $599/mo, through the Pro plan.
Can an exposed API key actually stall a fundraising round?
Yes. A live key, never rotated, sitting in a public file or an old commit. That is one of the most common findings a reviewer surfaces. It raises a fast question about the team's judgment. The product's strength does not matter here.
Does a cap table security audit cover code, or only legal records?
It used to mean legal records only: option grants, valuations, and equity history. In 2026, the same data room usually holds your architecture and security posture too. A reviewer checks both in the same pass.