The common advice I keep hearing is that you tidy the repo the week before the data room. I sat with a founder in Ahmedabad who did exactly that. He added a gitignore, rotated one Stripe key, and sent the GitHub invite. The partner cloned the history, not the latest commit.
The OpenAI key from a March experiment was still sitting in a deleted env file. The conversation stopped being about the market. It became a conversation about whether this team could be trusted with a customer’s data.
That week changed how I treat a seed product that wants institutional money. Cleanup is not diligence. Diligence is what a stranger finds when they are allowed to be unkind.
What a cleanup week actually fails to hide
Vibe-coded MVPs are honest about speed and dishonest about history. Cursor, Bolt, and v0 will write a working checkout. They will also commit STRIPE_SECRET_KEY because the prompt said make payments work.
A cleanup week fixes the working tree. A technical partner reads the log. According to GitHub secret scanning documentation, a credential that once landed in git is treated as compromised even after you delete the file. That is how the scanner is designed, not a scare line from a slide.
Database indexes are the second surprise. The demo has forty users. The partner runs the same query the dashboard runs, then asks what happens at forty thousand. If EXPLAIN shows a sequential scan on the tenant id, the product is still a prototype wearing a logo.
Tests are the third. “We click through before we ship” is not coverage. A partner looks for a CI job that can fail a pull request. If Playwright is not in the repo, they assume nothing is locked.
IP is the quiet one. Who wrote the eight thousand lines the model generated? Which contractor still has push access? Is there an assignment letter, or only a WhatsApp thread?
The OWASP project is blunt about leaked secrets and broken access. Data from the GDPR.eu site is equally blunt about what you must be able to find, export, and delete. A partner who has done this before will ask both questions in the same hour.
The three folders a partner actually opens
I now assume they will open three places and ignore the architecture slide. Git history. The schema. The test job. If those three are calm, we get to talk about the product.
The data room is a folder, not a story you tell about the folder.
Think of secrets as stains. Washing the shirt does not help if the laundry still has last month’s water. Rotate every key the scanner finds. Then treat the old ones as public. GitHub’s own documentation on removing sensitive data from a repository is clear: deletion of a file is not removal from history.
Indexes are cheaper than a rewrite. PostgreSQL documentation on using EXPLAIN is the rehearsal script. Run it on the ten queries the dashboard actually fires. Add a composite index where the plan is a sequential scan on tenant plus created_at. Do not index every column because a model suggested it.
Tests only count if they can stop a merge. A Playwright smoke on signup, login, and checkout is enough to start. Put it in CI. Make the job red when it fails. A green badge you never look at is decoration.
Why do VCs still fail a repo that works on my machine?
A repo that works on your machine still fails diligence when secrets sit in git history, queries have no indexes, tests are a manual click-through, or a contractor still owns a module. Working is a local demo. Diligence is whether a stranger can clone the repo, scan it, and trust what they find without calling you.
I have watched this in Pune as well. A product logged in, charged a test card, and generated a report. The partner asked for the CI file. There was none. The next question was not about the report. It was about how the team knew the login still worked after the last Friday push.
What does an IndiaNIC Diagnostic Audit actually inspect?
An IndiaNIC Diagnostic Audit inspects the same surfaces a Series A technical partner inspects: git history for secrets, schema and query plans, CI and Playwright coverage, contractor and generator IP, and a short GDPR data map. We write the findings as a folder you can put in the data room, not as a slide.
We run it as a clone, not a workshop. Someone who did not write the code opens the repo and behaves like a partner who is slightly late and slightly unkind. That is the point. Kind reviews miss the March key.
Do not send the invite until two things are true. git log -p cannot show a live key, and CI is red when the smoke test fails. Everything else can be a conversation. Those two cannot. |
A rehearsal you can run this week
Do not start with a rewrite. Start with the folder the partner will actually open. This is the order I use on an IndiaNIC Diagnostic Audit.
- Turn on secret scanning and push protection. Read every alert. Do not argue with the first one.
- Rotate every key the scanner finds. Stripe, OpenAI, database, OAuth. Write the rotation date in the data room.
- Accept that old keys are public. Rewrite history only if you understand the cost. Most seed teams should rotate and move on.
- Run
EXPLAINon the ten queries behind the dashboard. Add indexes where the plan is a sequential scan on a filter you use on every page. - Add a Playwright smoke for signup, login, and checkout. Hang it on CI so a red job blocks main.
- Collect assignment letters. List every contractor and every generator tool. Say who owns the output.
- Write a one-page data map: what personal data you store, where it lives, and how you delete it.
I have written more of these field notes on the IndiaNIC blog. The useful ones are the boring ones. Diligence rewards boredom.
What a pass looks like
Success is quiet. The partner clones. The scanner is silent. EXPLAIN uses an index. CI is green because the tests ran, not because someone skipped them. The IP folder has dates. You talk about the market.
The 2026 bar I keep seeing is not a full rewrite. It is a clean history, a failing test that actually fails the build, and a founder who can point at the data map without opening Slack.
If the last week before the data room is still your plan, change the plan. Run the unkind clone now. The partner will. The only question is whether they are the first person to do it.
Frequently asked questions
Should I rewrite git history or just rotate the keys?
Rotate the keys first, and treat every old secret as public, because scanners and clones will still see the old commit. Rewrite history only when you understand the cost to every fork and every laptop. Most seed teams should rotate, document the date, and stop promising that deletion made the past disappear.
If a partner asks, show the rotation log. That is a stronger answer than a force-push story.
How much Playwright coverage is enough for Series A?
Enough Playwright coverage for Series A is a smoke path that can fail the build: signup, login, and the one paid action your product sells. Partners are not counting assertions. They are checking whether anyone can merge a broken login. Add depth after the smoke job is red when it should be red.
I would rather see three honest tests than a generated suite nobody runs.
Does generated code hurt IP in diligence?
Generated code hurts IP in diligence when you cannot say who owns the output, which tools wrote it, and whether a contractor still holds rights. Partners expect an assignment letter and a short vendor list, not a claim that “the AI wrote it so it is ours.” Write that folder before they ask.
If a freelancer built a module, get the assignment before you send the invite. After the invite is too late to look calm.
