A workable software outsourcing contract should make five things unambiguous: what will be delivered, how acceptance works, who owns the work, how risk is controlled, and how either side can exit. For a typical 3–9 month build, buyers should expect the contract and statement of work to take 1–3 weeks to finalize once commercial terms are agreed. The checklist below is designed for buyers comparing domestic, offshore, or hybrid delivery teams; it is a commercial review aid, not a substitute for legal advice.
The biggest contract failures are rarely caused by one missing legal phrase. They happen when the contract does not connect scope, evidence, payment, and change control into one operating system.
The 20 clauses to review before signing
| # | Clause | What the contract should state | Evidence to request |
|---|---|---|---|
| 1 | Parties and contracting entity | Full legal names, registration details, addresses, signatories, and which office delivers the work. | Corporate registration and invoice entity. |
| 2 | Scope and exclusions | Named features, platforms, integrations, environments, data migration, and explicit exclusions. | Signed statement of work and prioritized backlog. |
| 3 | Deliverables | Source code, infrastructure scripts, designs, test assets, documentation, and deployment packages. | Deliverable register with owner and due date. |
| 4 | Milestones | Dates, dependencies, review windows, and the consequence of a missed dependency on either side. | Milestone plan with critical path. |
| 5 | Acceptance criteria | Measurable functional, performance, browser/device, security, and defect thresholds. | Acceptance test matrix before development starts. |
| 6 | Acceptance process | Who tests, where results are recorded, review period, rejection procedure, and retest timing. | Sample acceptance report and issue workflow. |
| 7 | Pricing model | Fixed price, time and materials, or capped time and materials; rates, assumptions, and currency. | Rate card or milestone price schedule. |
| 8 | Payment terms | Invoice trigger, payment period, taxes, bank charges, disputed invoices, and late-payment rules. | Example invoice and payment schedule. |
| 9 | Change control | How a request is estimated, approved, prioritized, billed, and reflected in schedule and scope. | Change-request template with impact fields. |
| 10 | Team and continuity | Key roles, expected allocation, replacement process, overlap period, and knowledge-transfer duty. | Named role plan and replacement SLA. |
| 11 | Communication | Working language, overlap hours, meeting cadence, escalation contacts, and decision log. | Sample weekly report and escalation matrix. |
| 12 | Client responsibilities | Access, content, approvals, test data, domain experts, and maximum response times. | RACI matrix covering buyer and vendor. |
| 13 | Intellectual property | Ownership of bespoke code and designs, transfer timing, pre-existing materials, and license terms. | List of background IP and third-party licenses. |
| 14 | Open-source software | Approval rules, license review, component inventory, and treatment of copyleft licenses. | Software bill of materials or dependency report. |
| 15 | Confidentiality | Protected information, permitted use, access limitations, survival period, and required disclosures. | NDA terms aligned with the main agreement. |
| 16 | Data protection and security | Data locations, sub-processors, access control, encryption, incident notice, retention, and deletion. | Security questionnaire, data-flow diagram, and access list. |
| 17 | Warranty and defect repair | Warranty period, severity definitions, response targets, exclusions, and what is repaired without charge. | Severity matrix and defect SLA. |
| 18 | Support and maintenance | Included hypercare, support hours, response/restoration targets, maintenance rates, and renewal terms. | Separate support schedule or service levels. |
| 19 | Liability and insurance | Liability cap, excluded losses, carve-outs, indemnities, and required insurance. | Insurance certificate where relevant. |
| 20 | Termination and exit assistance | Termination rights, notice, payment for completed work, data return, access transfer, and handover support. | Exit checklist, repository access, and handover rate. |
Choose a commercial model that matches uncertainty
The pricing clause cannot be reviewed in isolation. It must match how well the requirements are known and how often priorities are likely to change.
| Model | Best fit | Buyer control | Main contract risk |
|---|---|---|---|
| Fixed price | Stable scope with testable acceptance criteria | Strong budget ceiling; weaker reprioritization | Disputes over whether a request is included |
| Time and materials | Discovery, new products, or changing priorities | Strong scope control; variable total spend | Paying for activity without delivery visibility |
| Capped T&M | Known budget with moderate uncertainty | Flexible backlog within a ceiling | Unclear treatment when the cap is reached |
| Dedicated team | Six months or more of continuous product work | Direct priority control and stable capacity | Underused capacity or costly team churn |
For T&M or dedicated teams, ask for weekly timesheets by role, a fortnightly demonstration, and a monthly forecast of remaining budget. For fixed-price work, attach acceptance tests and a change-control form to the contract instead of relying on a short feature list.
Define acceptance before the first sprint
“Works as expected” is not an acceptance criterion. A useful acceptance schedule names the test environment, test owner, dataset, expected result, severity threshold, and review deadline. A practical review window is often 5–10 business days for a milestone, but the right period depends on release size and the buyer’s availability.
- Functional: each agreed workflow passes the attached test cases.
- Performance: named pages or APIs meet an agreed response target under a stated load.
- Compatibility: supported browsers, operating systems, and device classes are listed.
- Security: critical and high-severity findings are resolved or formally accepted.
- Defects: the number and severity of open defects allowed at acceptance are explicit.
Avoid automatic acceptance triggered only by silence when the buyer has not received a deployable build, release notes, and test evidence. If deemed acceptance is used, connect it to confirmed delivery and a reasonable review window.
Connect payment to observable progress
A balanced milestone schedule avoids both a large unsecured deposit and a final payment so large that it damages collaboration. One planning example for a fixed-price project is 10–20% at kickoff, 20–30% after approved design or architecture, 30–40% across working software milestones, and 15–25% after final acceptance and handover. The exact split should reflect procurement rules, project risk, and vendor mobilization costs.
For T&M, the contract should state role-based rates, minimum billing increments, overtime approval, currency conversion method, and whether meetings, project management, cloud charges, travel, and third-party licenses are billable.
Make ownership operational, not symbolic
An IP clause is incomplete if the buyer cannot access the assets. Require the source repository, cloud tenant, domain, analytics, design workspace, app-store accounts, and CI/CD environment to be created in buyer-controlled accounts where practical. Grant the vendor least-privilege access for delivery.
The contract should distinguish three categories: bespoke work created for the project, vendor background IP that existed before the project, and third-party or open-source components. If background IP is embedded in the deliverable, the buyer needs a license broad enough to operate, modify, maintain, and transfer the system to a replacement provider.
Security terms for an offshore or cross-border team
| Control area | Minimum question | Contract output |
|---|---|---|
| Access | Who can reach production data and from which locations? | Named roles, MFA, approval, and quarterly access review. |
| Data | What data crosses borders or enters development tools? | Data-flow map, approved locations, masking, and retention rules. |
| Sub-processors | Which hosting, monitoring, AI, and support providers receive data? | Approved list and change-notification procedure. |
| Incidents | How quickly must the vendor notify the buyer? | Notification window, escalation contacts, evidence preservation, and report duties. |
| Offboarding | How are credentials and copies removed? | Access revocation and deletion certificate within a defined period. |
Do not copy a security appendix from another project without mapping the actual architecture. A public-content website, an HR platform, and an AI agent using internal documents have different data flows and control needs.
Plan the exit while the relationship is healthy
Exit assistance should be priced and defined before it is needed. State the notice period, the number of included handover hours, additional hourly rates, required artifacts, and the time allowed to transfer accounts and answer questions. The buyer should receive current source code, deployment instructions, environment inventory, architecture diagrams, known-issue list, data export, credentials transfer, and license inventory.
Use the 25-point development vendor handover checklist to turn the exit clause into a verifiable delivery plan.
A practical contract review sequence
- Days 1–2: align the scope, commercial model, contracting entity, target date, and decision owners.
- Days 3–5: complete the statement of work, acceptance matrix, RACI, architecture assumptions, and data-flow diagram.
- Days 6–8: reconcile legal terms with the operating documents; resolve IP, security, liability, and termination gaps.
- Days 9–10: run a kickoff simulation: submit a change, reject a milestone, report a security incident, and trigger handover on paper.
- Before signature: confirm every attachment is versioned, referenced, and signed with the agreement.
Red flags to resolve before signing
- The scope says “complete platform” but has no exclusions, interfaces, or acceptance tests.
- Payment is tied only to calendar dates rather than delivered and reviewable work.
- The vendor owns all reusable components but the buyer receives no perpetual operating license.
- Production credentials are shared through chat or held only in a vendor-owned account.
- Change requests can be approved verbally without budget or schedule impact.
- The warranty excludes all integration defects even though integrations are part of the scope.
- Termination is allowed, but handover artifacts, timing, and rates are undefined.
FAQ
How much should legal and contract preparation cost?
Cost varies by jurisdiction, risk, and complexity. Budget separately for qualified legal review; operational documents such as the statement of work, acceptance matrix, RACI, and security questionnaire usually require meaningful input from product, engineering, security, and procurement rather than lawyers alone.
How long should contract negotiation take?
For a standard 3–9 month software project, 1–3 weeks after commercial alignment is a reasonable planning range. Regulated data, multiple countries, complex IP, or enterprise procurement can extend the process.
Who should own the source code?
The contract should normally assign bespoke deliverables to the buyer after the agreed payment condition is met. Pre-existing vendor tools and third-party components may remain separately owned, but the buyer needs sufficient licenses and a complete inventory.
What maintenance period should be included?
Separate defect warranty from ongoing maintenance. Define a warranty period and severity-based repair targets, then price enhancements, platform upgrades, monitoring, and operational support under a separate support schedule.
How should a cross-border team communicate?
Define the working language, daily overlap window, weekly reporting cadence, decision log, response expectations, and escalation path. A local contracting or communication layer can reduce commercial and language friction while retaining offshore delivery economics.
What should happen if the vendor relationship ends?
The exit clause should require repository, cloud, domain, data, documentation, credentials, licenses, and open-issue transfer on a fixed timetable. Include a priced block of transition support so handover does not depend on a future negotiation.
