Most custom software contract disputes do not start with bad intentions. They start with unclear scope, unpaid assumptions, and missing clauses that neither party noticed until something went wrong. By the time the dispute surfaces — a missed milestone, a feature the client assumed was included, code the developer considers out of scope — the negotiating dynamic has shifted completely. You need these protections before the first line of code is written, not after the first invoice is disputed.

Two facts set the stakes. First: only 31% of software projects succeed without scope disputes (Standish CHAOS Report). Over 50% of software projects exceed budget; more than half reduce scope to avoid further overruns. Second: paying for custom software does not automatically make you the owner of it. These are the two most expensive misunderstandings in software procurement, and both are prevented entirely by a correctly structured contract.

31%
of software projects succeed without scope disputes — meaning 69% involve some form of overrun, conflict, or scope reduction
Standish CHAOS Report
68%
of codebases contain open source license conflicts — AI-generated code accelerating the problem
Black Duck 2026 OSSRA
17%
of open source components enter codebases through AI generation — invisible to standard scanning tools
Black Duck 2026 OSSRA
3
conditions that must ALL be met before IP transfers in most contracts: complete + accepted + fully paid
Saigon Technology, July 2026
The single most important legal fact in software procurement
Paying for software does not make you the owner of it
Under US copyright law, code written by an independent contractor belongs to the contractor by default — not the client who commissioned it. Software cannot be made a "work made for hire" simply by including that phrase in a contract. "Work made for hire" applies to employees (not contractors) and to a narrow list of specific commissioned work categories that does not include software. To own the software you commission, the contract must include an explicit IP assignment clause — a written assignment of all intellectual property rights from the developer to the client. Without it, you are paying to license software you do not own, and the developer can legally use the same code in other projects, sell it, or refuse to give you the source code when the relationship ends.

Before the checklist — choose the right contract model

Three commercial models govern custom software contracts. The model you agree to determines which party bears overrun risk — and which clauses are most critical to negotiate. Choose the model that matches your scope certainty, then apply the relevant sections of the checklist below with the appropriate emphasis.

Model How it works Risk allocation Best for Critical clause
Fixed price Agreed total cost for a defined deliverable; vendor absorbs cost overruns Overrun risk: developer Well-defined scope; short projects; low probability of requirement changes Change-order process — every scope addition must be priced separately in writing. Without this, every "small" addition creates a dispute.
Time & materials Client pays for hours and resources consumed; scope can flex Overrun risk: client Evolving requirements; R&D and exploration projects; agile development with shifting priorities Rate caps and not-to-exceed ceilings — without a budget ceiling, T&M exposure is theoretically unlimited. Monthly budget reviews should be contractually required.
Milestone-based Fixed payments released on accepted deliverable phases; scope defined per milestone Risk split per milestone Most custom software projects above $25K — the most common and most balanced commercial structure Acceptance criteria — each milestone payment must be gated on specific acceptance tests, not just delivery of code. "Delivered" without acceptance criteria is not "done."

"Most disputes are not about the first spec; they are about the changes nobody priced. A change-order process matters as much as the original scope."

ailawyer.pro — Software Development Agreement: Scope, IP Ownership & Sample, 2026

The 8-section checklist — work through each before signing

Section 1 Scope of work and technical specification
Why this section matters: most disputes are not about bad intentions — they are about different assumptions about what was included. A scope document attached as an exhibit to the contract converts assumptions into contractual commitments.
  • Written technical specification attached as an exhibit. Not described in the main body — attached and signed. The specification defines what will be built in sufficient detail that a different engineering team could implement it. Vague scope is not scope.
  • Explicit exclusions listed. The scope document names what is NOT included. Integrations, platforms, device types, browsers, data migration, third-party licences — each exclusion prevents a future "I assumed that was included" dispute.
  • Formal change-order process defined. Any change to scope must be requested in writing, estimated by the vendor, and approved in writing by the client before work begins. Verbal scope changes are not binding on the vendor. Sprint-level additions without a change-order are a dispute waiting to happen. Critical
  • Scope freeze points identified. For fixed-price contracts, define the date after which scope cannot change without a formal change order and price renegotiation. Without this, "we thought of something else" is implicitly in scope.
  • Client obligations documented. What must the client provide, and by when? Access to systems, content, design assets, stakeholder decisions, API credentials, test data. Delays caused by client failures to provide these are typically the vendor's contractual justification for timeline extension.
Section 2 Milestones, acceptance criteria, and payment structure
Why this section matters: payment should track accepted progress, not calendar time. Every payment that releases without a corresponding accepted deliverable reduces the vendor's incentive to deliver the next one.
  • Milestone schedule with specific delivery dates and deliverable descriptions. Not "Phase 1: 30% of work" — each milestone should name what will be delivered, in what form, and by what date. Critical
  • Acceptance criteria per milestone. Before any payment triggers, what specific criteria must the deliverable meet? Tests to pass, features to demonstrate, performance benchmarks to hit. "The client reviews and approves" is not acceptance criteria — it is a subjective standard that becomes a dispute. Critical
  • Acceptance review period defined. The client has X business days after delivery to complete acceptance testing. Silence (no response) after that period should contractually constitute acceptance — to prevent the vendor being held hostage to an indefinite review.
  • Typical payment structure for custom software. 20–30% on contract signature; 40–50% across 2–3 intermediate milestone payments tied to accepted feature sets; 20–30% on final acceptance. Never 100% upfront. Critical
  • Payment not triggered by time elapsed. "30% due after 30 days" is not milestone-based payment — it is T&M with extra steps. Each payment must be triggered by a named accepted deliverable, not by calendar.
  • Late delivery remedy defined. What happens if the vendor misses a milestone delivery date? Is there a financial penalty, a credit, a right to terminate? "We'll work together to resolve it" is not a remedy.
Section 3 Intellectual property ownership and assignment
Why this section matters: this is the section most commonly missing from SMB software contracts, and its absence is the most expensive mistake. You must demand an explicit IP assignment — not a "work made for hire" clause (which does not apply to contractor-built software).
  • Explicit IP assignment clause — not "work made for hire." The contract must include an assignment of all intellectual property rights, including copyright in the source code and all derivative works, from the developer to the client. "Work made for hire" language in a contractor agreement is legally ineffective for software in the US. Critical
  • IP transfer conditions stated explicitly. Most contracts transfer IP only when all three conditions are simultaneously met: the work is complete, accepted, and fully paid. Confirm this — and ensure partial IP transfer rights are available if the engagement terminates early with partial work paid for.
  • Pre-existing materials / background IP declared. If the vendor brings pre-existing code libraries, frameworks, or tooling into the project, these should be declared. You need a licence to use them if they are not transferred. "We build everything from scratch" should be verified, not assumed.
  • AI-generated code ownership clause. In 2026, every developer uses AI coding assistants. The contract should explicitly state that all code generated using AI tools in the course of this engagement is covered by the IP assignment — and that the vendor warrants they have rights to assign AI-generated code consistent with the AI tool provider's terms of service. 2026
  • Source code delivery at milestones, not only at project end. The client should receive the current source code at each milestone, not only at project completion. This protects the client if the engagement terminates early — you receive code you have paid for, not a legal dispute over what was "complete."
  • No developer licence-back without client consent. Confirm the vendor does not retain a licence to reuse your custom code, UI components, or business logic in other client projects. Generic framework components should be declared separately from client-specific custom work.
Working with a software development agency?

Find agencies verified on contract transparency and delivery outcomes

TechRadiant verifies software development agencies on documented delivery outcomes — including IP transfer practices, milestone-based payment structures, and post-launch support track records. A verified agency has already been assessed on the contract and delivery criteria this checklist defines.

Find a verified agency → Browse verified software agencies
Section 4 Open source, third-party components, and AI-generated code 2026 addition
Why this section matters: 68% of codebases contain open source license conflicts (Black Duck 2026 OSSRA). 17% of open source components enter codebases through AI generation — invisible to standard manifest-based scanning tools. GPL, AGPL, and other copyleft licenses carry obligations that affect how you can distribute or commercialise your software. If the vendor introduces these without disclosure, you inherit the obligation.
  • Open source disclosure obligation. The vendor must disclose all open source components used in the project before delivery, including indirect (transitive) dependencies. The disclosure should include the component name, version, and licence type. 2026
  • Open source licence compatibility warranty. The vendor warrants that no open source component used in the project carries a licence obligation that would restrict the client's intended use, distribution, or commercialisation of the software. Copyleft licences (GPL, AGPL, LGPL) require disclosure and potentially licence propagation — this should be the vendor's obligation to identify and flag. Critical
  • Software Bill of Materials (SBOM) delivery requirement. For significant software systems, require the vendor to deliver a machine-readable SBOM (in SPDX or CycloneDX format) at project completion. An SBOM is a structured inventory of all software components — essential for security vulnerability management and increasingly required for regulated industries and government contracts. 2026
  • AI-generated code governance declaration. Require the vendor to disclose which AI coding assistants were used in the project and to represent that AI-generated code has been reviewed for open source licence contamination. AI coding assistants trained on public repositories can introduce latent GPL or MIT licence obligations invisible to standard scanning tools (HeroDevs, May 2026). 2026
  • Third-party licence cost disclosure. If the project requires paid third-party licences (API subscriptions, commercial libraries, database licences), these costs should be declared upfront in the contract. Surprises after delivery that require ongoing licence payments are a budget and IP exposure.
Section 5 Warranties, defect correction, and post-delivery support
Why this section matters: the warranty period is the only contractual window during which the vendor is obligated to fix defects at no additional charge. Without it, the first bug after delivery is a new engagement at a new price.
  • Post-acceptance warranty period defined. 30–90 days is the typical range. During this period, the vendor must correct material defects at no additional charge. Confirm this is in the contract, not just promised verbally. Critical
  • Defect severity levels and response times defined. Not all bugs are equal. The contract should define severity levels (critical/high/medium/low) with corresponding response and resolution time commitments. Example: critical bugs (system unavailable or data loss) fixed within 24–48 hours; major bugs (core feature broken) within 5 business days; minor bugs within 30 days. Verbal commitments about response time are unenforceable.
  • Distinction between defects and change requests. A defect is a deviation from the accepted specification. A change request is new functionality or behaviour not in the specification. The contract must define this distinction explicitly — otherwise every "it doesn't work the way I expected" becomes a disputed warranty claim.
  • Post-warranty support option defined. What happens after the warranty period? Is there a maintenance retainer option, a support SLA, or a time-and-materials rate for post-warranty work? Define this before project start — you will need it, and negotiating it after delivery is from a weaker position.
  • Conformance to specification warranty. The vendor warrants that the delivered software conforms to the agreed technical specification at the time of acceptance. This creates an enforceable quality standard independent of the warranty period.
Section 6 Limitation of liability, indemnification, and insurance
Why this section matters: liability and indemnification clauses determine who pays when something goes seriously wrong — a data breach, an IP infringement claim, or a production failure that causes business losses. These clauses are almost always negotiable, and the vendor's first draft will strongly favour the vendor.
  • Liability cap at a reasonable multiple of contract value. Most vendor contracts limit liability to the contract value or 1–2x contract value. Unlimited client liability is not acceptable — it exposes a small vendor's mistake to multi-million dollar claims. Unlimited vendor liability is also unrealistic — no contractor accepts it. 1–2x contract value is the standard negotiated position. Critical
  • IP indemnification clause. The vendor indemnifies the client against third-party claims that the delivered software infringes a third party's intellectual property. This is the protection that matters if an open source licence violation or AI-generated code copyright claim surfaces after delivery. Without it, the legal cost lands entirely on the client.
  • Data breach indemnification for vendor negligence. If the vendor's code causes a data breach due to security negligence (unencrypted PII, insecure API endpoints, failure to follow agreed security specifications), the vendor should bear proportionate liability. Define this scope specifically — not all security incidents are vendor responsibility, but those caused by deviation from agreed specifications should be.
  • Verify insurance certificates before signing. Require a current certificate of insurance (COI) showing Errors & Omissions (E&O) / Professional Liability and cyber liability coverage at minimums appropriate for your project value. A vendor without E&O insurance has no financial capacity to honour indemnification obligations when it matters.
Section 7 Termination rights, transition assistance, and data return
Why this section matters: the exit terms are what make a partnership healthy — when exit is realistic and fair, both parties behave better throughout the engagement. A contract with no termination rights creates a hostage dynamic that damages the relationship long before any dispute is formalised.
  • Termination for cause (both directions). Either party can terminate immediately if the other materially breaches the contract — the client for non-delivery or quality failure; the vendor for non-payment. Requires a written notice period (7–14 days) and a cure opportunity before termination takes effect. Critical
  • Termination for convenience (client right). The client can terminate the engagement with 30 days written notice, paying for work completed to date plus a termination fee (typically 10–25% of remaining contract value). This right must exist — without it, you are locked in regardless of performance, relationship quality, or changed business needs.
  • Work-in-progress delivery at termination. On any termination, the client receives all work completed and paid for at termination — source code, documentation, design files, database schemas, API specifications. The vendor's right to withhold work product as leverage for payment disputes should be addressed explicitly.
  • Source code escrow for business-critical systems. For software where vendor business failure would create an operational emergency, a source code escrow arrangement with a named neutral third party holds the production source code and releases it to the client on defined trigger conditions (vendor insolvency, material breach, cessation of support). 2026
  • Data return and deletion obligations. All client data held by the vendor must be returned in a specified format within a defined period after termination, and the vendor must certify deletion of all copies. Define the format, the timeline (30 days is typical), and the certification requirement.
  • Transition assistance obligation. The vendor must provide reasonable transition assistance — knowledge transfer, documentation, handoff support — during and after termination to enable the client to engage a replacement vendor or transition work internally. Duration (typically 30–60 days) and cost basis should be defined.
Section 8 Security requirements, confidentiality, and governing law
Why this section matters: security obligations that are abstract ("we take security seriously") are unenforceable. Confidentiality without duration or scope is barely better than nothing. And governing law determines where and how you can pursue a dispute — which matters more than most buyers realise until they need to enforce something.
  • Specific security requirements referenced as an exhibit. Security requirements should be named specifically — encryption standards (TLS 1.2+ in transit, AES-256 at rest), authentication method (OAuth 2.0, MFA requirements), OWASP compliance, specific compliance framework requirements (HIPAA, PCI DSS, SOC 2). "Industry standard security" is not a requirement. If the vendor cannot produce an exhibit, that is a stop sign (Arbisoft, February 2026). 2026
  • Security incident notification obligation. The vendor must notify the client within a defined period (typically 24–72 hours) of any actual or suspected security incident affecting client data. This requirement must be explicit — it cannot be assumed. Define the notification recipient and the minimum content of the notification.
  • Confidentiality scope and duration. Mutual NDA should cover all confidential information shared during the engagement. Duration should be defined (2–5 years is typical, some information perpetually) — "confidential information remains confidential" without a term creates ambiguity about obligations after contract end.
  • Governing law in your jurisdiction. The contract should be governed by the law of your jurisdiction (your state or country), not the vendor's. Disputing a foreign-law contract is significantly more expensive and complex. For offshore vendors, international arbitration clauses (ICC, LCIA) are a reasonable middle ground. Critical
  • Dispute resolution process before litigation. Define a mandatory escalation process — executive escalation, then mediation — before either party can initiate legal proceedings. This rarely stops serious disputes but meaningfully reduces the incidence of disputes over misunderstandings.

The 10 walk-away conditions — disqualifiers before negotiation

These conditions do not require detailed analysis — they indicate either bad faith or fundamental misalignment between what the vendor is willing to commit to and what good delivery requires. Any one of these present in a contract draft warrants a request for significant revision before negotiation proceeds. Multiple conditions warrant walking away entirely.

Walk away or revise significantly if any of these appear
01
No IP ownership or assignment clause — you may pay for software you don't legally own
02
100% payment upfront — zero vendor incentive to complete or fix the project
03
No milestones or deliverables defined — the project is never contractually "done"
04
No acceptance criteria — "delivered" is whatever the vendor says it is
05
No client termination rights — you are locked in regardless of performance
06
Unlimited client liability with no cap — one bug could expose you to claims exceeding the contract value
07
Vague scope with no change-order process — every "small addition" becomes a dispute
08
No post-delivery warranty — the developer accepts zero responsibility for quality after handoff
09
Foreign governing law for a domestic vendor relationship — enforcement is expensive and impractical
10
"Developer retains all rights" language — you are licensing, not owning, regardless of what you paid

This checklist covers the contractual protections that prevent most custom software disputes. The business protections — reference checks, portfolio verification, discovery call quality, team credential verification — are separate from contract review and equally important. For the full agency evaluation framework including those business-level due diligence steps, see our complete agency evaluation guide and our mobile app RFP template for the procurement step that comes before the contract.

⚠️ Legal notice: This article is educational material, not legal advice. Custom software contracts carry significant legal and commercial implications. Review any contract with a qualified attorney before signing, particularly for engagements above $50,000 or involving sensitive data, regulated industries, or international vendor relationships.