Six weeks into a proof of concept with our biggest prospect yet, their security lead emailed asking for read access to our source code repository. My first instinct was to say yes just to keep the deal moving. My second, better instinct was to ask why.
The question underneath the question
Nobody actually wants to read your code for fun. When a prospect asks for repo access, they're trying to close a specific risk in their own head, and "give me the source" is just the bluntest tool they know to reach for. Sometimes the real question is whether you have basic security hygiene. Sometimes it's whether a specific feature works the way your sales deck claims. Sometimes it's a checkbox their procurement team requires regardless of what their engineers actually need. Treating all three the same way, by handing over a repo, either overexposes you or wastes weeks negotiating an NDA for information nobody was going to use anyway.
Three questions before you answer yes or no
Before I respond to any code-access request now, I ask three things, and I ask them out loud on a call rather than guessing over email. First: what specific risk are you trying to close? If they can't name one, that's a sign the ask is a template from their security team's playbook, not a real blocker to signing. Second: would a narrower artifact answer this just as well? Most of the time, yes. Third: who on your side actually reviews this, and what do they do with what they find? If the answer is "our security team runs it through a static analysis tool and files a ticket," you can often get the same outcome by running that scan yourself and sharing the report.
What to offer instead of repo access
Four alternatives cover almost every version of this request I've seen. A redacted architecture walkthrough, a screen-share where you narrate the parts of the codebase relevant to their concern without handing over a clone-able repo, answers "how does this actually work" without exposing your full IP. A read-only sandboxed environment, a throwaway instance they can poke at, answers "does this do what you say it does" without touching source at all. A third-party security audit or pen test summary, even a lightweight one from a freelance security researcher, answers the security-hygiene question directly and is reusable across every future deal that asks the same thing. A source code escrow agreement, where a neutral third party holds a snapshot released only if you go out of business or breach the contract, answers the buyer's real fear, which is usually "what happens to our data and integration if this vendor disappears," not "I want to read your code today."
When full access is genuinely the right call
There are cases where none of the substitutes work and you should say yes to real access: regulated buyers like banks or government agencies where code review is a legal requirement, not a preference, and deals large enough that the legal cost of a proper NDA and controlled review process is worth it relative to the contract value. Even then, "access" should mean a supervised, time-boxed review on your terms, ideally in person or over a locked-down screen share, not an open invite to your GitHub org. The distinction that matters is between review and possession. Reviewing under supervision protects you. An unsupervised clone of your repo does not, no matter what the NDA says about it.
The script I actually use
When the request comes in now, I respond with a version of this: "Happy to get you what you need here. Before I loop in engineering, can you tell me what specifically you're trying to verify? Depending on the answer, we can usually get you there faster with a live walkthrough or our latest security audit report rather than a full repo handoff, which takes longer to set up on our end with proper access controls." That single question has redirected roughly four out of five of these requests toward something I can turn around in a day instead of a week, and it hasn't cost me a deal yet. The prospects who genuinely need full access tell you so directly once you ask; the ones running a checklist usually accept the substitute without pushback.
What I'd tell a founder facing this for the first time
Don't say yes reflexively and don't say no reflexively either. Ask what risk they're actually closing before you touch your repo settings. Have a redacted walkthrough, a sandbox, and a recent security scan ready before you need them, because building these under deal pressure is worse than building them once and reusing them for every prospect after. And if a deal genuinely requires full source access, treat it as a supervised review with a real process behind it, not a favor you grant to keep a prospect happy. The goal isn't to protect your code from every prospect. It's to make sure the access you grant actually matches the risk they're trying to close.