The NDA Before You Show Your Code: What It Should Say, What It Cannot Do, and Why Ours Is Mutual
Before a founder opens the repository, the lawyer wants a signature. That is the right call, and I say so as the person on the other side of the signature. The NDA is the first document a founder and a vendor write together, and it tells you more about how the engagement will go than the proposal does.
I sign one most months. Conectia takes over apps built with Claude Code, Cursor, Lovable, Bolt, v0 and Replit, and the work starts with read access to the repository, the database and the cloud console: the Diagnostic & Blueprint is two weeks of reading what exists. Nobody should hand that access to a company they met two emails ago without an agreement. This autumn a founder told me his counsel would draft the NDA before anyone saw the code. Two weeks later we signed it. It was our own template, filled in, which is the best review a legal document can get.
So this is not a post telling you to skip the NDA. It is a post about what the document has to say in 2026, what founders ask for that works against them, and the part most people get backwards: an NDA protects the conversation; access control protects the code.
An NDA that only flows one way tells you how the vendor thinks
The first thing I look at is the direction. A unilateral NDA, where only the founder discloses and only the vendor promises, is common and wrong for this job. During an audit the vendor discloses too: its method, its pricing, its tooling, and at the end a written verdict on your product that you can take to someone else. If we asked you to protect us while we read everything of yours, you should wonder what else we would ask for.
Ours is mutual by construction. Both parties are the disclosing party and the receiving party depending on who is talking, and the obligations read the same in both directions. It also costs nothing: the vendor who refuses mutuality is telling you that its paperwork was written for a different relationship, usually one where the client is a large company and the vendor is a body shop.
The definition has to name the things that exist now
Most NDAs in circulation were written before 2023. Their definition of confidential information says «business and technical information» and stops. That phrase did its job when the valuable part of a product was a database and some documents. In an AI-built app, the valuable and the dangerous parts are elsewhere, so our definition names them: source code and binaries, repositories, credentials and environments, data models, prompts, weights and configurations of AI models, customer data, pricing, and the existence and content of the conversation itself.
Two of those are new and matter more than they look. The system prompt of an AI feature is often where the product lives; a competitor who reads it has most of what you spent three months on. And credentials and environments belong in the list because an audit does not happen on paper: someone will log into your cloud console and your GitLab, and what they see there is confidential whether or not a document says «confidential» on top.
The last item is the one founders rarely notice. If the existence of the conversation is confidential, the vendor cannot name you as a client, put your logo on a slide or write a case study unless a later agreement says so. For a company raising a round or negotiating with an enterprise buyer, that silence is worth having in writing.
The clause nobody had three years ago: no training, no retention
Our clause 2.1(e) says the receiving party will not use the other party's information to train, fine-tune or evaluate general-purpose AI models, nor submit it to third-party services that retain the data or train on it, unless authorised in writing. In 2022 that sentence would have been exotic. Today it describes an ordinary working day: the engineers reading your code will do it with Claude Code, Cursor or Copilot open, because that is how senior people work now, and the question is under which terms those tools see your repository.
The answer is not «don't use them». It is to know the contract behind each tool. The commercial API terms of the main model providers do not train on customer inputs by default; the consumer apps run under a different agreement, and that is the gap the clause exists to close. In our case every tool that touches client code runs through our own orchestration platform against provider accounts with no training and no retention, inside the client's repository and cloud when they prefer it. Whoever your vendor is, ask for the list of services that will read your code and the terms behind each one. A vendor who cannot produce the list has not thought about it, and a clause they sign without being able to honour it is worth less than no clause at all.
Three clauses founders over-ask, and two they forget
The over-asking comes from templates built for acquisitions, not audits.
A non-compete. Asking a software company not to work with anyone in your sector for two years, in exchange for reading your code for a fortnight, is a request no serious vendor accepts and no court in Spain would enforce at that breadth. What you want instead is already in the agreement: the information cannot be used for any purpose other than evaluating the engagement.
A non-solicitation clause. Keep it, but not here. The promise not to hire each other's people belongs in the services contract, where the people, the term and the remedy are known. In an NDA it pre-decides a relationship that may never start, and it is the clause most likely to send the document back to the lawyers for a week you do not have.
Perpetual confidentiality for everything. It feels safer and it is weaker, because a term nobody can comply with is a term nobody takes seriously. Ours runs two years, with the obligations surviving three more, and for source code and anything that qualifies as a trade secret under Spanish Law 1/2019 the obligation lasts as long as the information keeps that status. That is the structure the trade-secret directive gave every EU jurisdiction: protection follows the secret, not the calendar.
What founders forget is more expensive.
Return and destruction that names where copies live. «Return all materials» meant something when materials were paper. An audit leaves copies of your code in a clone on a laptop, in a development environment, in a CI runner and in a Slack thread. The clause has to name repositories, environments and collaboration tools, give a deadline, and ask for written confirmation; ours says fifteen days. Backups are the honest exception: they exist, they expire, and they stay under the agreement until they do.
Personal data. The moment your app has a second customer, your database contains personal data of people who are not party to this NDA. If a vendor reads a production dump, you are a controller handing personal data to a third party, and the NDA alone does not make that lawful. Our clause 7 asks both sides to keep personal data out of the evaluation where possible, using anonymised or synthetic copies, and to sign a data processing agreement under Article 28 GDPR if the audit needs real data. This is also good engineering: the audit that runs against a masked copy of production is the audit whose findings you can share.
The general-knowledge clause is what makes the document signable by an engineer
Clause 4 lets each party keep using the general knowledge, skills and ideas its people retain in unaided memory, as long as doing so does not disclose the other party's information. Founders sometimes read it as a loophole. It is the opposite. A senior engineer who has read forty codebases cannot unlearn that a webhook needs an idempotency key because they saw yours without one; without this clause, every audit would make the auditor less employable, and the only people willing to sign would be the ones who do not read the fine print. The clause excludes deliberate memorisation to get around the agreement, and that is the right line.
I will concede the strongest objection to everything above: a well-drafted NDA has never stopped anyone determined to misuse code. It gives you a court in Barcelona two years later. What stops the misuse is what you do the morning you send the invitation.
What the NDA cannot do, access control does
The document governs intent; the access policy governs what is possible. The second is where I would spend the hour.
Read-only access, with a named account, not a shared one. On GitLab that is the Guest or Reporter role on the project, on GitHub a read permission on the repository, on the cloud a viewer role on the console and nothing on the production database beyond a masked replica. Set an expiry; two weeks is the length of a serious audit, and an invitation that lapses by itself is one less thing to remember. Keep every coding agent, yours or the vendor's, away from production: Replit's agent deleted a live database in July 2025 during a test it had been told to freeze, and no agreement would have restored the rows. When the audit ends, rotate the keys the auditor could have seen, which is also the first item on the fix list of any AI-built MVP, and keep the access logs: GitLab, GitHub and the cloud consoles all record who read what and when, which is more evidence than most NDAs ever produce.
What I'd do before sending the invitation
If the app were mine and a vendor had asked to read it, in this order:
- Ask for the vendor's mutual NDA first. If they only have a one-way document, send yours. Which paper you sign matters less than the fact that it binds both sides.
- Check five things in whatever you sign: that it is mutual; that the definition names code, repositories, credentials, prompts and model configurations; that it bans training and retention by third-party services; that it has a general-knowledge clause; and that the term survives for source code and trade secrets.
- Keep non-solicitation and ownership of the work for the services contract. The NDA covers evaluation. Everything about building goes in the next document.
- Grant read-only access with a named account and an expiry, and give the vendor a copy of the database with personal data masked. If they insist on production data, ask why the audit needs it.
- Ask, in writing, which AI tools will read your code and under which terms. Keep the answer with the signed NDA.
- Decide what the audit may be used for afterwards. The verdict is yours; the vendor's method stays theirs. The NDA already says so, and it saves an argument when you take the document to a second vendor, your own hire or the agent that wrote version one.
The signature protects the conversation; the invitation protects the code
A good NDA is short, symmetrical and specific about the things that exist in 2026: code, prompts, credentials, the training clause, personal data, and a term that follows the secret rather than the calendar. Sign one before anyone reads your repository, and do not let anyone talk you out of it. Then spend the hour that matters on the invitation itself, because the agreement tells you what the other side has promised and the access policy decides what they could do.
That is how every AI-built app we take to production starts: a mutual NDA in your inbox within a day, and a read-only invitation that expires when the two-week Diagnostic & Blueprint ends.
