IP ownership, NDAs, acceptance criteria, exit terms — the twelve clauses that decide whether an outsourcing contract protects you, and the red flags to walk away from.
Most outsourcing disputes are not caused by bad engineering. They are caused by a contract that never defined what “done” means, who owns the code, or what happens when the relationship ends. This checklist covers the twelve clauses that matter most — written from the client's side, and specific enough to check against a draft you have in front of you right now.
Ownership and confidentiality
1. IP assignment
The contract must state that all work product — source code, designs, documentation, and data — is assigned to you on creation, not on final payment. Watch for “licence” instead of “assignment”: a licence means the vendor still owns it. Include work by subcontractors explicitly.
2. NDA covering everyone who touches the project
A company-level NDA is not enough if individual engineers or subcontractors are not bound by it. Require that every person with repository or data access has signed, and that the vendor can produce evidence on request.
3. Pre-existing and third-party components
Vendors often reuse internal libraries. That is fine, but the contract should list them and grant you a perpetual, irrevocable, royalty-free licence. Separately, require an open-source policy: permissive licences only, with copyleft components disclosed and approved in advance.
Scope, quality, and money
4. Scope definition and change process
Define scope by reference to a specific document version, and define how changes are priced and approved — in writing, with an estimate, before work begins. A change process that lives only in chat messages is the single most common source of billing disputes.
5. Acceptance criteria
Specify what “complete” means: functional criteria, supported browsers and devices, performance thresholds, and a defined acceptance window — typically ten business days — after which undisputed deliverables are deemed accepted. Without this, either side can argue indefinitely.
6. Payment schedule tied to deliverables
Tie payments to accepted milestones rather than to calendar dates, and keep a final tranche of 10–20% held until handover is complete. For monthly engagements, agree the invoicing date, the payment window, and what happens to unused capacity.
7. Warranty period
Require 60–90 days after acceptance during which defects against the specification are fixed at no cost. Define what counts as a defect versus a change request — that boundary is where warranty clauses usually fail.
People, process, and security
8. Named team and replacement terms
Name the engineers, or at least their roles and seniority. Require notice before anyone is swapped, a handover overlap, and your right to request replacement if someone is not performing. Ban silent substitution of a senior engineer with a junior one.
9. Communication and reporting obligations
Put the working rhythm in the contract: an agreed daily overlap window, a weekly written status report, a demo cadence, and a defined escalation path with response times. This turns “poor communication” from a complaint into a breach.
10. Security and data handling
Specify where source code and data live — your accounts, ideally — who has access, how access is revoked, whether production data may be used in development (usually no), and any regulatory requirements such as GDPR that apply to your users' data.
Ending the relationship
11. Handover and exit terms
This is the clause most often missing and most expensive to lack. Require: complete source code with commit history, infrastructure-as-code or documented environment setup, architecture and deployment documentation, credential transfer, and a defined number of knowledge-transfer hours. Make final payment conditional on it.
12. Termination rights
Both sides should be able to terminate for convenience with 30 days' notice, and immediately for material breach after a cure period. Define what you pay on termination — work completed and accepted, not the remainder of the contract.
Read the exit clause before the pricing clause. A good rate on a contract you cannot leave is not a good deal.
Red flags worth walking away from
- IP transfers only on final payment — or is licensed rather than assigned.
- Code hosted exclusively in the vendor's repositories with no client access.
- No named engineers and no replacement terms.
- Refusal to define acceptance criteria in writing.
- No handover obligation, or handover priced as a separate project.
- Automatic renewal with a long notice period buried in the terms.
Frequently asked questions
- Who owns the code in an outsourcing contract?
- You do only if the contract assigns intellectual property to you on creation. Look for the word “assignment” rather than “licence”, make sure it covers subcontractors, and avoid terms that transfer ownership only after final payment.
- Is an NDA enough to protect my idea?
- An NDA protects confidential information but not ownership of what gets built — you need a separate IP assignment clause for that. Also confirm the NDA binds every individual with access to your code and data, not just the vendor company.
- What should a handover clause include?
- Full source code with commit history, documented environment setup or infrastructure-as-code, architecture and deployment documentation, transfer of all credentials and accounts, and an agreed number of knowledge-transfer hours. Tie the final payment tranche to completing it.
- Should the contract be under my jurisdiction?
- Your own jurisdiction is preferable, but enforcement across borders is slow and costly either way. In practice, structure the payment schedule and handover obligations so you are protected commercially — that matters far more than which court is named.
Conclusion
A good outsourcing contract is not about distrust; it is about removing ambiguity so both sides can focus on delivery. Work through these twelve clauses before signing and you eliminate most of the disputes that derail projects. If you would like a partner who puts these terms in writing by default, talk to 2Tech Global.