Software Outsourcing Contract Checklist: 18 Terms to Get in Writing

Direct answer: A software outsourcing contract needs 18 terms in writing across five areas: commercial (pricing model, payment milestones, change request process, rate lock), delivery (definition of done, acceptance criteria and test window, warranty period), people (key person clause, replacement SLA, mutual non-poaching), operations (SLA response times, reporting, audit rights, security and data processing), and exit (termination notice, transition assistance, source handover, post-termination consequences).

The 5 Contract Categories Most Agreements Get Wrong

Most outsourcing contracts cover the two things everyone remembers to negotiate, price and timeline, and stay silent on the sixteen terms that decide whether the engagement survives its first hard moment: a missed deadline, a departed engineer, or a decision to walk away. An NDA and a one-page SOW are a starting point, not a contract.

The 18 terms below sort into five groups, each answering a different question the relationship will eventually ask:

Pricing model mechanics, fixed price versus time and material versus a capped hybrid, get a full clause table in Fixed Price vs Time & Material. This checklist treats pricing as one line among 18 and stays focused on the full set. Want a contract built around these terms from the start? Talk to MONA about your engagement →

Commercial Terms: Pricing, Milestones, Change Control, and Rate Lock

Commercial terms decide who carries cost risk and how money disagreements get resolved before they become disputes.

• Pricing model and rate card. Why: sets who owns estimation risk. Norm: the contract names the model, fixed price, T&M, T&M with a cap, or dedicated retainer, and attaches a signed rate card by role and seniority. Red flag: a vendor who won't commit rates to a signed exhibit, only "confirms later per resource."
• Payment milestones. Why: ties cash flow to accepted work, not the calendar. Norm: roughly 20 to 30 percent at signing, 40 to 50 percent across two to three milestones tied to accepted deliverables, and a final 10 to 20 percent held back until the warranty period closes (source: fynk, Genie AI). Red flag: milestones tied to dates, not deliverables, or no holdback at all.
• Change request process. Why: without one, "just one small addition" expands scope for free. Norm: a written change form, a fixed turnaround for the vendor's cost and time estimate, commonly 5 to 10 business days, and mutual written sign-off before the change starts (source: Ironclad, fynk). Red flag: changes confirmed only verbally or over chat.
• Rate lock. Why: protects your budget against a mid-engagement rate hike. Norm: rates locked for a fixed term, 12 months is typical, with any increase requiring advance written notice and a stated cap. Red flag: no lock period, so the number in your contract is only ever a starting quote.

Delivery Terms: Definition of Done, Acceptance, and Warranty

Delivery Terms: Definition of Done, Acceptance, and Warranty (AI-generated illustration)

Delivery terms are where most outsourcing disputes actually start: both sides believed the work was finished and disagreed on what that meant.

• Definition of done. Why: without one, "finished" means whatever the vendor says it means. Norm: define done at the feature level, code merged, tests passing, documented, deployed to a named environment, as a contract exhibit. Red flag: "done" deferred to "mutual agreement" with no written criteria.
• Acceptance criteria and test window. Why: sets a clock on how long you have to find problems before payment is owed regardless. Norm: a written testing window per milestone, commonly 5 to 15 business days, with a defect-severity scale and an explicit right to reject with itemized reasons. Red flag: no test window, so silence at delivery counts as acceptance.
• Warranty period. Why: decides who fixes post-launch defects for free versus who bills them as new work. Norm: 30 days is the common baseline for straightforward builds; complex or high-stakes systems run 90 days to a year, and iterative delivery often uses a shorter 30-day window per release instead (source: Tech Contracts, Garage Technology Ventures). Red flag: no warranty clause, or "material defects" left undefined.

People Terms: Key Person, Replacement, and Non-Poaching

You're usually buying trust in two or three specific senior people, not "a team" in the abstract. These three terms keep that trust from quietly evaporating.

• Key person clause. Why: nothing stops a vendor from reassigning the architect or PM you were pitched, unless the contract says so. Norm: name the key roles in a contract exhibit and require written client approval before any of them moves off the account (pattern reflected across Law Insider). Red flag: senior staff feature in the sales deck, but the contract names no one.
• Replacement SLA. Why: people leave; what matters is how fast and how well they're replaced. Norm: a written commitment to propose a replacement of equal or greater seniority within a fixed window, commonly two to four weeks for standard roles, plus a funded knowledge-transfer period (pattern reflected across Law Insider). Red flag: no replacement timeline, or quality left entirely to the vendor's discretion.
• Mutual non-poaching. Why: protects both sides, you from the vendor recruiting your staff, the vendor from you hiring theirs to cut them out of the fee. Norm: a mutual clause covering the engagement plus 12 to 24 months after termination is the most commonly accepted range (source: OGC). Red flag: a one-directional clause restricting only you, or none at all.

Operational Terms: SLAs, Reporting, Audit Rights, and Data Security

Operational terms govern the engagement day to day, and they're the ones most often left to "we'll figure it out."

• SLA response times. Why: "we'll get to it" isn't a commitment; a severity-tiered SLA is. Norm: tier by business impact, commonly critical (response inside an hour, escalation on a fixed clock), high (one to two hours), medium (four to eight hours), and low (one business day) (source: Atlas Systems, Email Meter). Red flag: one flat response time for every issue.
• Reporting cadence. Why: you can't manage a bill you can't see, especially on hourly or dedicated-team engagements. Norm: a written weekly status report (hours burned versus budget, milestones, blockers) plus a monthly summary you could forward to your own leadership unedited. Red flag: reporting "on request" only, with no written baseline.
• Audit rights. Why: gives you a contractual, not goodwill-based, path to verify the vendor is doing what the contract and any data terms say. Norm: the right to audit records, security practices, and hour logs on reasonable written notice, commonly 10 to 30 days (source: Venminder, Atlas Systems). Red flag: no audit clause, or one needing the vendor's consent to use.
• Security and data processing. Why: if the vendor ever touches customer data or production access, this clause makes them contractually liable for a breach, not just embarrassed by one. Norm: a data processing addendum specifying data location, access controls, a breach-notification timeline (commonly 24 to 72 hours), and subprocessor disclosure, matched to whatever regulation applies to your data. IP ownership of the code itself is a related but separate topic, covered in Protecting Your IP When Outsourcing Software. Red flag: "we take security seriously" with no addendum and no named subprocessors.

Exit Terms: Termination, Transition, Handover, and Consequences

Exit Terms: Termination, Transition, Handover, and Consequences (AI-generated illustration)

Every engagement ends, well or badly, and exit terms decide which. They're also the thinnest terms in most contracts, because nobody enjoys negotiating a divorce clause on day one.

• Termination for convenience and notice. Why: lets either side exit a relationship that's stopped working without proving fault. Norm: technology contracts commonly use 60 to 90 days notice; outsourcing-specific agreements often run 90 to 180 days, given the transition work involved (source: ContractKen, Scott & Scott LLP). Red flag: only for-cause termination, which requires proving breach.
• Transition assistance. Why: notice alone doesn't guarantee a working handover; this clause obligates the vendor to help you land the work elsewhere. Norm: a defined period, commonly 30 to 90 days, during which the vendor documents systems, answers a successor team's questions, and keeps key staff available, billed at standard rates. Red flag: assistance left as "reasonable cooperation" with no defined scope, timeline, or billing terms.
• Source code and access handover. Why: determines whether you actually own what you paid for the day the relationship ends. Norm: unconditional transfer of source code, credentials, documentation, and infrastructure access, not held back as leverage; larger engagements often add source code escrow, a neutral third party holding a current code copy released on defined trigger events such as vendor insolvency (source: Escode, KTS Law). Who owns the copyright and when it assigns is covered in Protecting Your IP When Outsourcing Software. Red flag: source code "available on request," or handover conditioned on a disputed payment.
• Post-termination consequences. Why: without this, termination day becomes a scramble over half-finished invoices and live production access. Norm: the contract states what survives, confidentiality, IP assignment, non-poaching, and what settles immediately: final invoice reconciliation, revoked access credentials, written confirmation data has been returned or destroyed. Red flag: a termination clause silent on what happens next.

The Full 18-Term Checklist

Print this, attach it to your next redline, and check off what's actually in writing, not just discussed on a call.

Red Flags: What It Means When a Vendor Pushes Back

A vendor resisting one term isn't automatically disqualifying, some points are genuinely negotiable by deal size, but the pattern of resistance tells you something:

• "We don't usually put that in writing." If it's reasonable enough to promise verbally, it's reasonable enough to sign. This answer on a key person clause, replacement SLA, or transition assistance means the vendor wants flexibility you won't have.
• Everything pushed toward "case by case" or "mutual agreement." These phrases sound reasonable and mean nothing enforceable. Ask what happens in the specific case where you disagree.
• No named point of contact for contract questions, only sales. A vendor whose delivery or legal team can't answer a clause question before signing won't get faster once you're a client.
• Resistance concentrated in exit terms specifically. A vendor happy to negotiate pricing and SLAs but vague on termination notice, transition assistance, or source handover is telling you what they expect the ending to look like.
• "Every client signs our standard agreement." A standard template is a fine starting point; refusing any redline at all on a multi-month engagement is not.

If you're still choosing between vendors rather than negotiating with one, the vetting process itself is covered in How to Choose an Offshore Development Company. Want a contract built around all 18 of these terms from the start? Get in touch with MONA →

Frequently Asked Questions

What should be included in a software outsourcing contract?

At minimum, 18 terms across five categories: commercial (pricing model, payment milestones, change process, rate lock), delivery (definition of done, acceptance criteria, warranty), people (key person clause, replacement SLA, non-poaching), operations (SLA response times, reporting, audit rights, data security), and exit (termination notice, transition assistance, source handover, post-termination terms).

How long should a termination notice period be in an outsourcing contract?

Technology contracts commonly use 60 to 90 days notice for termination for convenience, while outsourcing-specific agreements often run 90 to 180 days given the transition work involved. Shorter notice on a long-running engagement usually means there's no real transition-assistance clause backing it up.

What is a key person clause and why does it matter?

A key person clause names the specific senior individuals who must stay assigned to your account and requires your written approval before any of them is reassigned. Without it, the experienced team in the sales pitch can be swapped for a junior bench with no recourse.

Do I need a source code escrow for outsourced software development?

For short or low-stakes engagements, unconditional source code handover written into the contract is usually enough. For long-running or business-critical builds, a source code escrow held by a neutral third party and released on defined trigger events adds protection an ordinary handover clause doesn't cover.

What's a reasonable warranty period for custom software?

Thirty days is the common baseline for straightforward web or app builds. More complex or high-stakes systems typically warrant 90 days to a year, while teams delivering in short iterative releases often use a 30-day warranty per release instead.

How is a contract checklist different from an NDA or a statement of work?

An NDA only protects confidentiality, and a typical SOW only defines scope and price. Neither addresses what happens if a key engineer leaves, how a "done" dispute gets resolved, what SLA governs support requests, or what happens to your source code if the relationship ends, which is what the other 14 terms on this checklist cover.