A software development contract has one job: to decide in advance who pays when something goes wrong. Almost every clause that matters is about a bad outcome, which is exactly why buyers skim them during the optimistic phase of a relationship and read them properly during the expensive phase. The 14 below are the ones we have seen decide real disputes.
This is written from the vendor side, which makes it unusual and, we think, more useful. We are telling you what to negotiate against people like us. It is a commercial checklist and not legal advice, so have counsel review anything above a modest contract value. It covers custom development agreements, MSAs, and SOWs.
The 14 clauses
1. IP assignment and when it transfers
The default should be that you own everything: source code, designs, documentation, and infrastructure configuration. Watch for assignment conditioned on full payment of all invoices, which is standard and reasonable, versus assignment on project completion, which is not. If a project ends early in a dispute, completion-based assignment means the vendor owns work you already paid for.
Negotiate to: IP transfers progressively as each invoice is paid.
2. Third-party and pre-existing components
Vendors reuse internal libraries and boilerplate. That is normal and it makes your project cheaper. What is not acceptable is discovering later that a core component is licensed to you rather than owned by you, with a fee if you change vendors.
Negotiate to: a written schedule of any pre-existing or third-party components, each with a perpetual, irrevocable, transferable, royalty-free licence. Plus a warranty that no copyleft licence contaminates your codebase, which matters if you ever sell the company.
3. Acceptance criteria and the acceptance window
The most common source of disputes. "Client shall accept the deliverable" with no definition means the vendor decides when they are done.
Negotiate to: written acceptance criteria per deliverable, a defined testing window (10 to 15 business days is normal), and a rejection process specifying that the vendor fixes defects at their cost. Deemed acceptance after silence is fair, but only if the window is realistic.
4. Change orders, with a rate and a clock
Scope will change. The question is whether changing it is a negotiation or a procedure.
Negotiate to: a pre-agreed hourly rate for changes, a maximum turnaround for the vendor to quote one (48 to 72 hours), and a written statement that work outside the SOW does not begin without your approval. That last clause protects you from surprise invoices and protects the vendor from unpaid work, which is why a good vendor will agree readily.
5. Payment schedule tied to deliverables
Time-based milestones ("30% at month two") pay for elapsed calendar rather than progress.
Negotiate to: payment tied to accepted deliverables. Deposits of 20% to 30% are legitimate; anything above 50% before meaningful delivery shifts too much risk to you. Keep a final 10% to 15% holdback until after a defined post-launch period.
6. The warranty period
How long the vendor fixes defects free of charge. Thirty days is common and too short for anything substantial.
Negotiate to: 90 days minimum, defining a defect as a deviation from the agreed specification rather than "anything the client dislikes." Both sides need that definition. Also specify a response time for critical defects.
7. Source code access and escrow
You should have commit access to the repository from day one, not a zip file at the end. This is non-negotiable and any resistance to it is disqualifying.
Negotiate to: your own organisation account, vendor added as collaborators, from the first commit. Escrow is only relevant when the vendor hosts the code themselves, which is an arrangement you should decline anyway.
8. Team continuity and key personnel
You evaluated a team. Nothing stops the vendor rotating everyone out after signature unless the contract says otherwise.
Negotiate to: named key personnel, minimum notice before replacement (10 to 15 days), replacement of equivalent seniority, and no billing for the replacement's ramp-up period.
9. Data protection, residency, and subprocessors
Essential for offshore engagements and increasingly a procurement gate.
Negotiate to: a DPA with defined roles, a named list of subprocessors with notice before changes, agreed data residency, a breach notification window (24 to 72 hours), and deletion or return of all data within 30 days of termination.
10. Confidentiality that survives
Mutual NDAs are standard. Two details are frequently wrong: the survival period, which should be 3 to 5 years past termination, and whether the vendor may name you as a client. Decide that deliberately rather than discovering a press release.
11. Termination for convenience
The most valuable clause in the entire document, and the one most often absent.
Negotiate to: either party may terminate on 30 days' written notice; you pay for work completed and accepted plus work in progress; all IP transfers; the vendor delivers a written handover including architecture, credentials, and deployment process. A vendor confident in their delivery will sign this. Resistance to it is the strongest negative signal in any negotiation.
12. Limitation of liability
Vendors cap liability, usually at fees paid. That is normal and you will not remove it.
Negotiate to: carve-outs from the cap for breach of confidentiality, data breach caused by vendor negligence, and IP infringement. Those three are where real damage lives, and capping them at fees paid means a $60k contract caps a data breach at $60k.
13. Post-launch support terms, agreed now
Maintenance runs 15% to 30% of build cost annually. If the rate is not set in the original contract, you will negotiate it from zero leverage the day something breaks.
Negotiate to: a defined support rate, response and resolution SLAs by severity, and a stated inclusion or exclusion of bug fixes versus new work. See why run cost dominates total cost on AI systems in particular.
14. Dispute resolution and governing law
For cross-border work, a clause naming a court eight time zones away and 18 months of process is functionally a clause saying "you will not sue us."
Negotiate to: escalation to named executives first, then mediation, then arbitration under a recognised body with a neutral seat. Arbitration is faster and cheaper than litigation for contracts in this range.
Quick reference
| Clause | Weak version | What to hold out for |
|---|---|---|
| IP transfer | On project completion | Progressively, as invoices are paid |
| Acceptance | Undefined | Criteria per deliverable + 10 to 15 day window |
| Change orders | "To be discussed" | Pre-agreed rate + 72hr quote SLA |
| Payment | Calendar milestones | Accepted deliverables + 10 to 15% holdback |
| Warranty | 30 days | 90 days, defect defined against spec |
| Repo access | Handover at end | Your org, day one |
| Team | Unnamed | Named, notice before replacement |
| Termination | Absent or cause-only | 30 days for convenience, either side |
| Liability | Capped on everything | Carve-outs for data, confidentiality, IP |
| Support | Silent | Rate + SLA agreed up front |
The five red flags that should end the conversation
- No termination-for-convenience clause, and resistance to adding one. It means the vendor's plan for a failing project is to hold you in it.
- IP conditioned on anything other than payment. Non-negotiable.
- They host the repository and will not give you access. Your code is being used as collateral.
- Over 50% payment before meaningful delivery. Cash-flow problems become your risk.
- "We do not usually change our standard agreement." Every professional vendor negotiates. Refusal signals either inexperience with real clients or a document with something in it worth defending.
What a good vendor will actually agree to
For calibration, here is what we sign as a matter of course, and what we would push back on. Use it as a benchmark, not as a claim of uniqueness.
| Term | Our position |
|---|---|
| Client owns all IP, transferring as invoices are paid | Standard, always |
| Client's repository from commit one | Standard, always |
| 30-day termination for convenience | Standard, always |
| 90-day warranty on defects against spec | Standard, always |
| Named team with replacement notice | Standard, always |
| Unlimited liability on all heads | We push back. Carve-outs yes, uncapped exposure no |
| Fixed price on unstable scope | We decline. It makes the project adversarial by month two |
| Zero deposit | We push back. 20% to 25% is how a team gets allocated |
Frequently asked questions
Who owns the code when you hire a development agency?
You should, unconditionally, with transfer occurring as invoices are paid rather than at project completion. Watch for pre-existing vendor libraries embedded in your product: those should carry a perpetual, irrevocable, transferable, royalty-free licence listed in a schedule to the contract.
What should a software development contract include?
At minimum: IP assignment, acceptance criteria, a change-order process with a pre-agreed rate, a deliverable-linked payment schedule, a warranty period, source code access, named key personnel, data protection terms, termination for convenience, liability limits with carve-outs, post-launch support rates, and dispute resolution.
Is a 30-day termination clause normal?
Yes, and its absence is a warning sign. Termination for convenience with 30 days' notice, payment for accepted and in-progress work, full IP transfer, and a written handover is a standard mutual protection. A vendor confident in their delivery loses nothing by signing it.
How much deposit is reasonable?
Twenty to thirty percent. That covers team allocation and initial work. Above fifty percent before meaningful delivery transfers too much risk to you, and it often indicates the vendor is funding current work with your money rather than from reserves.
What warranty period should I ask for?
Ninety days minimum, with a defect defined as a deviation from the agreed specification rather than subjective dissatisfaction. Thirty days is common and too short: most defects that matter surface after a few weeks of real user traffic, not in the first fortnight.
Should liability be capped at fees paid?
Capping general liability at fees paid is standard and you will not remove it. Insist on carve-outs for three things: breach of confidentiality, data breach caused by vendor negligence, and IP infringement. Without those, a $60,000 contract effectively caps your exposure on a customer data breach at $60,000.
Key takeaways
- Every clause that matters describes a bad outcome. Read them before you feel optimistic.
- IP should transfer as invoices are paid, never on project completion.
- Termination for convenience is the most valuable clause and the most often missing.
- Agree the support rate and change-order rate before signing, while you still have leverage.
- Carve confidentiality, data breach, and IP infringement out of the liability cap.
Before you sign anything
If you have a contract in front of you and something feels off but you cannot name it, that instinct is usually right and it is usually one of the 14 above. Send us the clauses you are unsure about, even if the contract is with another vendor, and we will tell you which are standard, which are aggressive, and which we would refuse. We do this fairly often for people who do not end up hiring us, and we would rather the industry got better at this than worse. Related: engagement models compared, what offshore development actually costs, and what to do when a build has already gone wrong.