Software Outsourcing Contract: Types, Must-Have Clauses and Red Flags
This article explains how software outsourcing contracts usually work, based on our experience as a vendor. It isn't legal advice, and contract law differs by state and by country. Have a US-licensed lawyer review any agreement before you sign it, especially the IP, liability, data protection and governing law terms, and ask them about the vendor's local law if the vendor is abroad.
How the documents fit together
A well-structured outsourcing relationship separates the terms that rarely change from the ones that change every few months. That's the job of the MSA and SOW split, and it saves weeks of legal back-and-forth each time you start a new phase.
| Document | What it covers | When it's signed |
|---|---|---|
| NDA | Confidentiality of what you share during sales and scoping | Before the first detailed call or code review |
| Master Services Agreement (MSA) | IP, confidentiality, warranties, liability, termination, payment mechanics, non-solicit, governing law | Once, at the start of the relationship |
| Statement of Work (SOW) | Scope, deliverables, team, timeline, price, acceptance criteria, assumptions | For each project, phase or team |
| Data protection addendum (DPA, BAA) | CCPA/CPRA service provider terms; a HIPAA business associate agreement for health data; GDPR Article 28 terms if EU data is involved | With the MSA, if personal data is involved |
| Change request / change order | A change to scope, team, timeline or price under an existing SOW | Whenever something changes |
| Service level agreement (SLA) | Response and resolution times, uptime, reporting, service credits | For support and maintenance work |
Two rules make this work. State which document wins in a conflict (usually the MSA, unless a SOW explicitly overrides a named clause). And keep legal terms out of the SOW: a project manager's "the vendor guarantees delivery by March" can quietly override the careful liability language in the MSA.
Contract types: fixed price, time and materials, dedicated team
The pricing model decides who carries which risk, so it shapes every other clause. Here are the three main models, plus the hybrid we recommend most often.
How it works: an agreed price for an agreed scope, usually paid in milestones (for example 20/30/30/20).
- Best for: small or medium projects with a detailed specification and designs, MVPs with a hard budget, audits and other bounded work.
- Who carries the risk: the vendor carries estimation risk and prices it in, typically 15–30% above an equivalent time-and-materials estimate.
- Clauses that matter most: a precise scope with an explicit "out of scope" list, acceptance criteria per milestone, a change request process with rates for extra work, and what happens to payment if you terminate halfway.
- Where it goes wrong: every ambiguity in the spec becomes a negotiation. Vendors protect margin by reading the scope narrowly; clients try to read it broadly.
How it works: you pay for hours actually worked, at agreed rates per role, usually invoiced monthly with timesheets.
- Best for: products under active development, unclear or changing requirements, ongoing improvement and maintenance.
- Who carries the risk: you carry the budget risk; the vendor is responsible for skill, effort and honest reporting.
- Clauses that matter most: rate card and annual increase cap, a monthly budget cap or approval threshold, timesheet and reporting obligations, the right to request replacement of people.
- Where it goes wrong: without a cap and regular burn reports, hours drift. A good T&M contract still has a forecast, and the vendor has to warn you when it's at risk.
How it works: a monthly fee per named person working full-time on your product. You set priorities; the vendor provides, manages and replaces people. See dedicated development team structure for how these teams are usually put together.
- Best for: long-term product development (6+ months), team extension, companies that want control without hiring.
- Who carries the risk: you carry delivery risk; the vendor carries staffing risk (availability, quality, replacement).
- Clauses that matter most: named key personnel, replacement time (2–4 weeks is reasonable), trial period per engineer, notice period for scaling down (usually 30 days per person), non-solicit fee and conditions for hiring people directly.
- Where it goes wrong: "dedicated" people who are quietly shared with another client. Ask for exclusivity in writing.
How it works: a fixed-price discovery phase (2–6 weeks) produces scope, architecture and estimates; development then runs on time and materials or a dedicated team, with a budget cap per phase.
- Best for: most new products. You get price certainty where it's possible and flexibility where it isn't.
- Clauses that matter most: what the discovery deliverables are, that you own them and can take them to another vendor, and how the estimate from discovery limits the next phase (for example, a cap at the estimate plus 15%).
- Where it goes wrong: a discovery phase that's really a sales exercise. Insist on deliverables you could hand to any vendor, as in our business analysis work.
The clauses that matter, and what good looks like
Every MSA has these sections. For each we note what we consider standard and where clients most often get caught.
1. Intellectual property
Under the US Copyright Act, code written by a vendor's people belongs to the vendor (as their employer) unless it is assigned to you in writing. Many US templates call the deliverables "work made for hire". That label only works for a contractor's work in nine statutory categories, and software rarely fits any of them, so on its own it can leave you with nothing. A sound clause does both: it calls the work made for hire to the extent the law allows, and it also states that the vendor "hereby assigns" all rights to you. The usual trigger is payment of each invoice. That's fair to both sides and far better than "on final delivery", which can leave you without rights to months of paid work if the project stops early.
- Pre-existing IP: the vendor keeps its own frameworks, tools and libraries and grants you a perpetual, royalty-free, irrevocable license to use them in your product. Ask for a list of anything significant.
- Open source: require the vendor to follow a policy (no strong copyleft licenses such as GPL or AGPL in distributed code without your approval) and to keep a list of dependencies.
- The chain of rights: the vendor's contracts with its employees, contractors and subcontractors must pass rights to the vendor. Ask for a warranty that they do. With a foreign vendor this depends on local law: Polish law, for example, requires a transfer to list the "fields of exploitation", and many civil-law countries in Latin America and Europe treat authors' moral rights as non-transferable, so the clause should include a waiver or consent to the extent local law allows.
- Further assurances: the vendor signs whatever is needed later to register or enforce your rights, for example in a patent filing or an acquisition's due diligence.
2. Confidentiality
Mutual, covering business information, code and data, and lasting 3–5 years after the relationship ends (indefinitely for trade secrets and source code). If you signed an NDA earlier, the MSA should replace or incorporate it, so you don't have two conflicting regimes.
3. Acceptance
Acceptance turns "done" into a contractual fact, and on fixed-price work it triggers payment. Define the criteria (tests passed, stories met, no open critical or major defects) and a review period, commonly 5–10 business days. Vendors will ask for deemed acceptance when the period lapses or the software goes into production. That's reasonable if the period is long enough for your team to actually test.
4. Warranty
On fixed-price work, 30–90 days after acceptance during which the vendor fixes defects against the spec for free is standard. T&M and dedicated-team contracts usually only warrant that work is done professionally by qualified people, since you pay for bug-fixing time anyway. Nobody competent signs a "bug-free" warranty, and those who do don't mean it.
5. Limitation of liability
This is where most negotiation time goes. The market standard for software services is a cap equal to the fees paid or payable in the previous 12 months, plus an exclusion of indirect damages such as lost profits. The carve-outs (things the cap doesn't apply to) matter more than the number:
- Breach of confidentiality
- IP infringement indemnity
- Data protection breaches, often with a separate, higher "super-cap" (2–3× annual fees) rather than unlimited liability
- Gross negligence, willful misconduct and fraud, which courts in many US states, including New York, won't let a contract cap anyway
- Your payment obligations
Be realistic: a vendor billing $40,000 a month can't carry unlimited liability for your business, and one that signs it either has very good insurance or doesn't intend to honor it. Ask for proof of professional liability insurance and size the cap to it.
Size the liability cap and your exit exposure
A notice period over 60 days on a T&M or dedicated-team contract is above market. Thirty days is the common standard.
A cap below six months of fees is low for a long engagement. Ask for 12 months or a fixed floor.
Illustrative figures for discussion with your lawyer. Many contracts use "fees paid in the previous 12 months", so the cap is smaller in the first year; ask for a minimum amount to cover that.
6. Indemnities
The vendor indemnifies you against third-party IP claims over its deliverables; you indemnify it for materials and data you provide. Mutual and narrow is normal. A broad indemnity "for any loss arising from the services" is not.
7. Term and termination
- For convenience: usually 30 days' notice on T&M and dedicated-team contracts; on fixed price you pay for work done plus committed costs. Watch for vendor notice periods shorter than yours.
- For cause: material breach not fixed within 15–30 days of written notice, insolvency, or repeated breaches.
- Exit assistance: handover of code, docs, credentials and knowledge at normal rates for a defined period. It's the clause clients most often wish they'd read carefully.
- Survival: IP, confidentiality, liability, payment and non-solicit should survive termination.
8. Non-solicitation
Vendors stop you hiring their engineers directly during the contract and typically 6–12 months after. Fair versions allow hiring for a conversion fee (often three to six months of the person's fees) and exclude people who answer a public job ad. Push back on flat bans, penalties of a year's fees or periods over 12 months; overly broad no-hire clauses may not be enforceable at all, and California courts in particular are skeptical of them.
9. Data protection: CCPA, HIPAA and, when relevant, GDPR
If the vendor accesses personal data on your behalf (a production database, support tickets, analytics, hosting), US law expects written terms. Which ones depends on the data and on who your users are.
- CCPA/CPRA and other state laws: if the California Consumer Privacy Act applies to you, the vendor is a "service provider" or "contractor", and the contract must limit its use of the data to the stated business purpose, prohibit selling or sharing it, require it to comply with the CCPA and notify you if it can't, let you take reasonable steps to stop unauthorized use, and pass the same terms to subcontractors. Roughly 20 other states, including Virginia, Colorado, Connecticut and Texas, now have comprehensive privacy laws with similar processor-contract requirements. One addendum written to the strictest of them usually covers the rest.
- HIPAA: if you are a covered entity or business associate and the vendor will create, receive, store or transmit protected health information, you need a business associate agreement before it touches the data. Offshore vendors can sign BAAs, but many health clients restrict PHI access to US-based staff anyway.
- Breach notice: all 50 states have breach notification laws with their own deadlines, and HIPAA allows at most 60 days. Ask the vendor to notify you within 24–72 hours of discovering an incident, with the facts you need for your own notices.
- Security and sub-processors: list the technical and organizational measures in an annex, list the sub-processors, keep a right to object to new ones, and require deletion or return of data at the end.
When GDPR comes in. If you process personal data of people in the EU, or your vendor is in the EU (as Gilzor is, in Poland), the GDPR applies to that processing and Article 28 GDPR requires a written contract with specific content: processing only on your documented instructions, staff confidentiality, security measures, sub-processor controls, breach notification without undue delay (ask for 24–48 hours, since a controller has 72 hours to notify the authority), help with data subject requests, audit rights and deletion at the end. Transfers of EU data to a US company can rely on the EU-US Data Privacy Framework if you're certified, or on the EU standard contractual clauses if you're not.
The best data protection clause is not giving the vendor production personal data at all: anonymized or synthetic test data removes most of the risk and the paperwork. For EU-side help, see our list of GDPR compliance companies in Europe.
10. Change requests
Either side proposes a change in writing, the vendor estimates the impact on cost, time and risk within a set number of days, and nothing changes until both sign. On T&M, backlog changes approved by the product owner are enough for priorities, but team size, rates and budget caps still need a written change order.
11. Service levels (for support and maintenance)
Define severity levels and times. A common business-hours pattern: critical issues get a response in 1–2 hours and a workaround in 4–8; major in 4–8 hours; minor next business day. Buy 24/7 only for systems that need it. Service credits for missed targets, capped at 10–20% of the monthly fee, keep SLAs honest.
12. Governing law, venue and disputes
US clients usually ask for New York or Delaware law. Both have deep commercial case law, and New York lets parties choose its law for contracts of $250,000 or more even without a connection to the state. Foreign vendors often propose their own country's law. The governing law matters less than where you can enforce: a judgment from a New York court has to be recognized by a court in Poland, Mexico or Colombia before it bites, which takes time and money. An arbitration award is enforceable in more than 170 countries under the New York Convention. A common middle ground is US law with arbitration under ICDR, ICC or JAMS rules, seated in New York or another neutral city, one arbitrator for smaller claims, and a carve-out letting either side go to court for urgent injunctions, for example to stop a leak of source code.
13. Contractor status and misclassification
The contract should say the vendor is an independent contractor, employs or engages its own people, pays their salaries, taxes and benefits, and indemnifies you if anyone claims otherwise. For engineers based in the US, misclassification is a real risk: the IRS uses a common-law control test and states such as California apply the stricter ABC test, so a long-term "contractor" who works only for you, on your schedule, under your managers, can be reclassified as your employee. For offshore teams the risk shifts to the vendor's country. Mexico's 2021 outsourcing reform, for example, bans subcontracting personnel for a client's core activities and requires providers of specialized services to register with the labor ministry (REPSE), with the client jointly liable if they don't. Ask for the registration or the local equivalent, and keep HR decisions such as hiring, pay and discipline with the vendor.
14. Export controls and sanctions
Sending source code or technical data to a team abroad is an export under US rules. Most commercial software needs no license, but a few things do: encryption beyond mass-market products, defense-related work under ITAR (which offshore teams generally can't do without authorization), and anything going to comprehensively sanctioned countries and regions such as Cuba, Iran, North Korea and the occupied regions of Ukraine, with broad restrictions on Russia and Belarus. Screen the vendor and its owners against the OFAC sanctions lists, and have the vendor warrant that nobody accesses your code or systems from a sanctioned country and that it complies with US export and sanctions laws.
15. Payment, rates and the boring rest
Payment terms of net 15–30 days, invoices in US dollars (so the vendor carries the currency risk), a cap on annual rate increases (CPI or a fixed 3–7%), and rules for expenses and travel. A foreign vendor should give you a W-8BEN-E form; payments for services performed entirely outside the US are generally not subject to US withholding, but confirm with your accountant. If the contract is bilingual, state that the English version prevails.
Built by Gilzor
Results we’ve shipped
Talk to the people who build it. Tell us about your project — get a free estimate of scope, timeline and cost.
Checklist: is your contract ready to sign?
Tick what your draft already covers. Progress is saved in your browser, so you can come back to it with the next draft.
Software outsourcing contract readiness
Red flags in a software outsourcing contract
The clauses we've seen cause real damage, in contracts clients brought to us when switching vendors and in drafts from clients' lawyers. Some favor the vendor, some the client; both kinds end relationships badly.
| Red flag | Why it matters | Ask for instead |
|---|---|---|
| IP transfers "on final delivery" or "on full payment of the project" | If the project stops at 70%, you've paid for code you don't own | Assignment on payment of each invoice |
| No mention of pre-existing IP or open source | Your product may depend on code you can't legally use after you leave | A list of vendor components with a perpetual license; an open source policy |
| Vendor holds the repositories, cloud accounts or domain | Leaving becomes a negotiation, and access becomes a bargaining chip in any invoice dispute | Everything in your accounts from day one, with vendor access you can revoke |
| Termination only for cause, or 90+ days' notice | You're locked in even when it isn't working | 30 days for convenience on T&M and dedicated teams |
| No exit or handover clause | The vendor can charge whatever it likes for the handover, or slow-walk it | Defined exit assistance at standard rates for a set period |
| Unlimited liability demanded from the vendor | Serious vendors refuse or price it in; those who accept may not be able to pay | 12 months' fees, with a higher super-cap for data and confidentiality |
| Vague scope with a fixed price | Every grey area becomes a dispute or a change request | A discovery phase first, or T&M with a cap |
| Unrestricted subcontracting | Your work may be done by a company you never vetted, in a country you didn't agree to | Subcontracting only with written consent; named sub-processors in the DPA |
| Non-solicit with no conversion option and a penalty of a year's fees | You can never keep the engineer who knows your system best | 6–12 months with a reasonable conversion fee |
| No privacy terms or BAA while the vendor accesses production data | A CCPA, HIPAA or GDPR compliance gap that lands on you, not the vendor | A data protection addendum (plus a BAA for health data), or no production personal data at all |
| Vendor's home law with its local courts as the only forum | Any claim means litigating abroad, in another language, under unfamiliar rules | New York or Delaware law with international arbitration (ICDR, ICC or JAMS) |
| "Work made for hire" with no assignment clause | For contractor-written software the label often fails, leaving ownership with the vendor | A present assignment ("hereby assigns") alongside the work-for-hire language |
A vendor that won't share its MSA until you've agreed on price is telling you something. Terms like replacement time, notice period and IP trigger affect the real cost as much as the hourly rate. Ask for the template with the proposal, and compare vendors on both.
From first call to signed contract: a realistic timeline
- NDA and scoping (week 0–1)Sign a mutual NDA before sharing code or detailed plans. Use the vendor's standard one if it's mutual and short; negotiating an NDA for two weeks is a poor start.
- Proposal and contract template together (week 1–2)Ask for the MSA template with the proposal. Read the IP, liability, termination and non-solicit clauses before you compare prices. Our breakdown of nearshore software development rates helps you check the price side.
- Legal review and redlines (week 2–4)One or two rounds of comments is normal. If you're on round five, the problem isn't the wording.
- First SOW: a bounded start (week 3–4)A discovery phase or a 4–8 week pilot with clear deliverables. It tests the relationship before the larger commitment.
- Run the change process from day one, review at renewalEven small changes get written down. It feels bureaucratic in month one and saves the relationship in month nine.
Contracts don't make a vendor good, but they make the relationship survivable when things go wrong. Pair a clear contract with a good process: our guides on how to manage a dedicated development team and staff augmentation vs consulting cover the operational side, and the benefits of outsourcing software development covers whether outsourcing is the right call in the first place.
FAQ
What should a software outsourcing contract include?
What is the difference between an MSA and a SOW?
Who owns the code when you outsource software development?
Is a fixed-price or time-and-materials contract better?
Do I need a data processing agreement with my software vendor?
Which governing law should a US company choose with a foreign vendor?
Where Gilzor fits
We work with startups, SMBs and product companies from teams in Poland and Cyprus. As a vendor outside the US, we expect US clients to ask about IP assignment, governing law, data protection and export screening, and we're glad to go through our own contract against this checklist. 85% of our customers come back for further work, which says more about a vendor than any single clause.
Whether you need a dedicated team, a fixed-price project, or a discovery phase through business analysis, talk to us and we'll explain how we'd structure the contract for your case.
Co-Founder of Gilzor. Works with founders and product companies on how to staff and run engineering: team extension, dedicated teams, and getting stalled projects moving again.
Gilzor · Business Analysis partner
Need a team for your product?
Services
Business AnalysisRequirements, scope and roadmap before development.→By company type
Selected projects
The team behind them
