Direct answer: An NDA protects your idea from being disclosed. It does not, on its own, guarantee you own the code that gets built. The clause that actually determines ownership is the IP assignment clause in the master services agreement — and it needs to say "assign all rights," not "grant a license to use." Read that one paragraph before you read anything else in the contract.
This confusion — treating the NDA as the whole protection — is one of the most common and most costly mistakes international buyers make when hiring an offshore development team. Here is what each document actually does, and what to check before you sign either one.
NDA and IP assignment solve different problems
An NDA (non-disclosure agreement) stops the other party from sharing or reusing confidential information you give them — your business plan, your data, your unique approach. It says nothing about who owns the software once it is built. Ownership is determined separately, by the IP assignment clause inside your master services agreement or statement of work. Treat them as two separate protections, both necessary, neither substituting for the other.
When an NDA is a reasonable ask — and when it is not
A general discussion of "we want to build a delivery app" rarely needs an NDA — that idea alone has little standalone value and most agencies field similar inquiries constantly. Once the conversation moves into specifics that carry real competitive value — a proprietary matching algorithm, real user data, a detailed go-to- market plan — asking for a mutual NDA before continuing is standard and reasonable. A vendor that stalls or refuses at that point, without a clear reason, is worth questioning.
The IP assignment clause: what it must say
Read this clause literally, word for word. It should state that all deliverables — source code, UI/UX designs, documentation, and custom-built components — become your exclusive property upon full payment, and that the vendor assigns those rights rather than merely licensing them to you. "We grant you a license to use the software we build" sounds similar but is a fundamentally weaker position: it can imply the vendor retains underlying ownership and could theoretically restrict, resell, or reuse the same code elsewhere. Insist on assignment language, not license language.
What legitimately stays outside exclusivity
Not everything a vendor writes should become your exclusive property, and a vendor insisting otherwise is unusual. Third-party open-source libraries, the vendor's own internal frameworks or boilerplate reused across projects, and generic utility code not specific to your business logic normally remain outside the exclusivity clause — you get a license to use them as part of your product, but the vendor keeps using them elsewhere too. What should be explicitly and fully yours is the custom application logic, business rules, data models, and branded output built specifically for your project. A well-drafted contract draws this line clearly instead of leaving it vague.
Ownership on paper means nothing without a real handoff
An assignment clause is only as good as your actual access to what it covers. Before signing, confirm you will receive: full repository access under your own git organization (not a fork you can be locked out of), your own App Store/Google Play developer accounts and cloud infrastructure credentials from day one — not handed over at offboarding — and documentation sufficient for a different team to pick up the codebase if needed. For the deeper version of this checklist, see our guide to vetting a mobile app development company and our enterprise mobile app architecture guide, which covers handoff terms for larger builds in more depth.
What "enforceable" actually means across borders
A written IP clause is necessary but not sufficient — real buyer anxiety about offshore contracts usually comes down to a specific unasked question: if the vendor breaches this agreement, what does recourse actually look like? Two things matter more than the clause wording itself. First, which jurisdiction the contract specifies for disputes — a contract silent on this, or one that names a jurisdiction where you have no practical ability to litigate, offers weaker real protection than the clause language might suggest. Second, whether the vendor is a real, identifiable legal entity you could actually pursue — a registered company with a verifiable address and business registration is a materially different counterparty than an individual freelancer or an unregistered team, regardless of what the contract says. Ask directly which jurisdiction governs the agreement and ask to see the vendor's business registration before treating the IP clause as your main protection — the clause states what you are owed; the jurisdiction and counterparty determine whether that is practically collectible.
Red flags in a vendor contract
Watch for vague or missing IP language altogether (silence is not protection — see above), a clause that grants you a "perpetual license" instead of ownership, retained rights for the vendor to showcase your project in a portfolio without your consent, and any clause that ties source code release to an ongoing support subscription rather than to payment for the work itself. None of these are automatically dealbreakers, but each should be a specific question you ask before signing, not something you discover after a dispute starts.
For a full comparison of engagement structures — including how ownership terms typically differ between a dedicated team and a fixed-scope project — see our dedicated team vs. project-based outsourcing guide. For the full picture of how we structure international engagements, our international hiring page covers pricing, contracts, and process end to end.
Frequently Asked Questions
For a first conversation about a general idea, usually not — the idea itself is rarely what has value, and most credible agencies will discuss scope at a high level without one. Once you are sharing specifics that matter competitively (a unique algorithm, a dataset, a business model with real detail), a mutual NDA before that conversation is a reasonable and normal ask. A vendor who refuses to sign one at that point is a real red flag.
This depends on jurisdiction and is exactly why it must not be left unstated. In many jurisdictions, the default rule for a commissioned/contracted work does grant ownership to the party who paid for it, but this is not universal and depends on local law, whether the developers are employees or contractors, and how the agreement is worded. Do not rely on a legal default — every serious contract should contain an explicit written IP assignment clause rather than leaving ownership to be inferred.
That all deliverables — source code, designs, documentation, and any custom-built components — become your exclusive property upon full payment, that the vendor assigns (not merely licenses) all rights, and that the vendor retains no rights to reuse your code or resell derivative work. "We grant you a license to use the software" is a materially different — and worse — clause than "we assign all rights to you." Read this clause word for word; it is the single most consequential paragraph in an outsourcing contract.
An NDA protects information you share before and during the engagement from being disclosed or reused — it is about confidentiality. An IP assignment clause determines who legally owns what gets built. Both matter, but they solve different problems: an airtight NDA with no IP assignment clause still leaves you without clear ownership of the finished product.
Only if your contract lets them — which is exactly why the IP assignment clause needs to be explicit rather than assumed. Reputable vendors should be willing to write in that any custom application logic, business rules, or branded output built specifically for you is yours exclusively, while shared open-source libraries, in-house frameworks, and generic utility code the vendor uses across projects normally remain outside that exclusivity — that distinction should be spelled out, not left ambiguous.
This should be defined in the contract before it becomes a real dispute — commonly, ownership of completed and paid milestones transfers as agreed, while work in progress that has not been invoiced or paid typically remains the vendor's until settled. Ask specifically how a mid-project termination is handled before signing, not after a disagreement starts.