An NDA keeps a conversation confidential. IP clauses decide who owns the repository when money has changed hands. Buyers mix them up. Vendors sometimes like that, because a thick MSA can hide a one-line "we license you the software" where you thought you bought the source.
This is the checklist we use before Myrafy sees a private codebase - and what you should demand from any engineering company, including us. It sits on top of what belongs in a SOW. The NDA is the door. The SOW is the purchase.
What the NDA Is For (and Not For)
Sign a mutual NDA when you will share non-public product plans, customer data shapes, credentials, or source. A public marketing site does not need one.
A useful NDA:
- Names the parties (your company, their company - not "the developer on Upwork")
- Limits use to evaluating or performing the work
- Says how long confidentiality lasts (often 2-5 years; source and trade secrets can be longer)
- Allows the disclosures the law already requires
- Does not assign copyright, lock you into a build, or set price
If the NDA tries to own "all ideas discussed," stop. That is an IP grab wearing a confidentiality hat. Evaluation should leave you free to hire someone else with your own notes.
We would rather start on a direct contract than a platform that inserts a third party between you and the IP.
Who Should Own the Repo
Default that you own the Git organization on day one. The company you hire is granted access. They do not fork your product into their account "for convenience."
On payment for each deliverable (or milestone), you should receive:
- Copyright assignment or a clear work-for-hire statement for the custom code written under the SOW
- All source, IaC, and runbooks in your org
- A short list of third-party licenses (libraries, fonts, models) so you are not surprised by AGPL or a training-data clause
"We will hand over a zip at the end" is how laptops become the system of record. If an engineer is hit by a bus, the bus should not have the only clone.
Open-source libraries they already maintain can stay theirs; your product code should not. If they want to reuse an internal starter, list it as a licensed component with an escape (you can keep running it if the engagement ends).
Work for Hire vs License
| Phrase | What it usually means | What to do |
|---|---|---|
| Work made for hire / assignment on payment | You own the custom work | Prefer this for product code |
| Perpetual license to use | They still own it; you may use it | Fine for a product they sell; wrong for a bespoke app |
| License until final payment | Hostage | Use escrow or milestone assignment |
| "Background IP" undefined | They can claim the architecture | List background tools; assign foreground work |
Lawyers will argue about "work made for hire" across jurisdictions. The practical test: can you hire another company next month with the same repo and no extra permission? If not, you do not own it.
Secrets, Data, and Subprocessors
An NDA does not replace access control. Before anyone clones:
- Issue time-limited repo and cloud roles
- Keep production data out of laptops; use anonymized fixtures
- Do not paste keys into the NDA packet - see stop committing secrets to git
The SOW should name subprocessors (hosting, email, AI APIs). Enterprise security review lives here, not in a slogan on the NDA.
What Must Be in the SOW, Not Only the MSA
MSAs are where payment, liability, and governing law live. They are a bad place to hide scope. Repeat in the SOW:
- Repo URL and who is org owner
- Assignment on milestone payment
- What happens to work-in-progress if the contract ends early (you still get what you paid for)
- Open-source and model terms
A 40-page MSA with "develop software as requested" and a license grant is how you get a surprise. Startup vs enterprise changes the questionnaire, not this rule.
Red Flags
- Vendor GitHub org as the only copy
- IP transfer only after a balloon payment with no escrow
- NDA that forbids you from hiring their people and from talking to any other vendor about the same problem for a year
- "Our AI trained on your repo" buried in background IP
- Reluctance to name who will actually have clone access
Years in the title, CIN blocks, or logo walls do not fix a bad assignment clause.
FAQ
Do we need an NDA to get an estimate? Not for a public brief. Yes before you send credentials, customer PII, or private source. A one-page mutual NDA is enough to start; do not wait for a 20-page MSA to ask for a free estimate.
Can they show our work as a case study? Only with written permission, and not until you agree the story is true. We label representative patterns until a named study exists. Demand the same honesty.
What about design files and prompts? Treat them as deliverables. If they produced the Figma or the eval set on your dime, it should land in your drive, not their "internal toolkit."
The Bottom Line
NDA and IP when you hire a software company are two documents. The NDA protects the conversation. The SOW plus assignment puts your product in your repository. License-only custom work is a rental.
Sign the boring versions. Clone the repo in your org before the first sprint.
Need an NDA and a SOW that names the repo? See how we work, browse services, or contact us.