Overview
A Software Development Agreement governs one of the most complex commercial relationships in modern business: the creation of custom software by one party for another. Unlike buying off-the-shelf software, custom development involves creating something that doesn't yet exist — which means the contract must define not just the transaction but the process, the outcome, and the ownership of something that will be built over time.
The stakes are enormous. Failed software projects are among the most expensive commercial disputes, routinely running into the millions. The reasons for failure are well-documented: scope creep without formal change control, payment disputes over incomplete deliverables, ownership battles over who controls the finished code, and warranty disputes over software that doesn't perform as expected. Every one of these failure modes is addressable in a well-drafted SDA — and almost none of them are addressed in the typical short-form agreements that developers hand to clients.
Three issues dominate SDA practice. First, IP ownership: who owns the code? By default under US copyright law, the developer owns what they write unless the contract says otherwise. Most clients assume they own commissioned code — they're legally wrong without an explicit written assignment. Second, acceptance: what does "done" mean? Software is uniquely difficult to accept because "working" is not binary — software can pass all specified tests and still fail to do what the client actually needed. Third, scope: what exactly is being built? Changes to requirements mid-project are inevitable, but without a formal change order process, they generate either unpaid work or disputed extra charges.
The SDA intersects with several other legal frameworks: IP law (copyright in code, potential patent issues in novel algorithms), data protection law (if the software handles personal data), open source license compliance, and export controls for software with encryption or dual-use capabilities. A comprehensive SDA must account for all of these dimensions.
Key Clauses to Review
Specifications and Scope of Work
The technical and functional specification attached to the SDA defines exactly what is being built. This is the single most important document in the entire agreement. The specification should cover: functional requirements (what the software does), technical requirements (languages, frameworks, infrastructure, performance benchmarks), integration requirements (APIs, third-party systems), security requirements, and design specifications. For agile projects, a product backlog with acceptance criteria per story serves this purpose. Both parties must sign off on the specification before development begins.
Specifications described only in business terms without technical detail — "a platform like Uber for X" is not a specification. Missing performance benchmarks (response time, concurrent users, uptime). Specifications that reference future requirements to be determined — scope ambiguity is the primary driver of project disputes. No design mockups or wireframes incorporated by reference. Specifications that can be unilaterally modified by the client without a formal change order process.
Intellectual Property Ownership and Assignment
Explicitly assigns ownership of the developed software, all code, documentation, and related IP from the developer to the client upon payment. Must include original code, modifications, derivative works, and all work product. Must also address pre-existing IP: code libraries, frameworks, and tools the developer brings to the project. Pre-existing IP typically remains with the developer, with a perpetual license granted to the client. The boundary between new IP (assigned to client) and pre-existing IP (licensed to client) must be clearly drawn in a technology schedule or IP annex.
Missing IP assignment entirely — the default rule gives copyright to the developer. Vague assignments of "work product" without specifying code, documentation, and derivative works. No pre-existing IP schedule identifying what the developer retains. Developer retaining a broad license to reuse client-specific code in other client projects. IP assignment conditioned solely on final payment with no interim assignment of completed milestones — leaving the client with no IP rights if the project is terminated mid-stream.
Acceptance Testing and Criteria
Defines the process and criteria by which the client determines whether delivered software meets contractual requirements. A robust acceptance process includes: a defined testing period (typically 10-30 business days per milestone), specific acceptance criteria tied to the specification, written acceptance or rejection mechanism, a defect classification system (critical vs. minor), remediation timelines for rejected deliverables, and a deemed acceptance provision if the client doesn't respond within the testing period. Acceptance should be tied directly to milestone payments.
No formal acceptance process — payment due on delivery without testing rights. Acceptance criteria defined as "client satisfaction" — subjective standards invite dispute and bad-faith rejection. Unlimited rejection rights without obligation to specify defects, allowing clients to withhold payment indefinitely. No deemed acceptance provision — clients can delay acceptance indefinitely by not responding. Testing periods longer than 30 days per milestone that extend the project timeline unnecessarily.
Payment Milestones and Schedule
Ties payment to objective project milestones rather than calendar dates or pure time-and-materials billing. A typical structure: 20-30% upfront at contract signing, 20-30% at mid-project milestone, 20-30% on development completion and acceptance, 10-20% on final go-live. For agile projects, sprint-based payments keyed to sprint acceptance work well. Every milestone should be defined by an objective, verifiable deliverable — not by time elapsed or developer effort alone.
Large upfront payments (over 30%) with no corresponding deliverable milestone. No payment for work completed before termination for convenience — developers deserve compensation for real work. Retainage provisions holding back final payment indefinitely. Milestone payments contingent on client actions entirely outside the developer's control. No interest provision for late payments.
Change Order Process
The formal mechanism for handling scope changes — additions, modifications, or deletions from the original specification. Every SDA needs a change order process that specifies: how changes are requested (in writing only), how the developer estimates the impact (time, cost, timeline), how the client approves or rejects the estimate, and what happens to the project timeline when changes are approved. Without this process, every scope change becomes a dispute: developer says extra work, client says it was included.
No change order process — the number-one driver of SDA disputes. Verbal change order authorization without written follow-up. Change orders that address cost but not timeline impact. Developer obligation to implement changes before cost and time impact are agreed. Client right to require changes without additional compensation. No mechanism to pause the project while change order impact is assessed.
Warranties and Post-Delivery Bug Fixes
Covers the developer's obligation to fix defects in delivered software. Structured in two phases: a warranty period (30-90 days post-acceptance) during which the developer fixes bugs at no charge, and optional post-warranty maintenance governed by a separate agreement. The warranty covers defects in conformance with specifications — not every performance issue, user complaint, or new feature request. Must clearly distinguish between warranty bugs (covered), change requests disguised as bugs (require change orders), and user error (not covered).
Indefinite warranty periods that make the developer responsible for the software forever. Warranty covering "any defect" without limiting to specification non-conformance. No process for distinguishing bugs from change requests. Developer warranty that software will be free from all security vulnerabilities — no software meets this standard. Missing source code escrow provisions for business-critical applications.
Risk Assessment
IP ownership disputes in software development are among the most expensive technology litigation. The core problem is simple: developers write code, clients pay for it, both assume they own it, the contract is ambiguous, and courts side with developers in the absence of a written assignment. A client who builds a business on custom software and later discovers the developer retains copyright has limited options — negotiate a license (expensive), litigate (more expensive), or rewrite (most expensive).
Scope creep is the primary cause of software project cost overruns. Studies consistently show 50-80% of software projects exceed budget, and scope creep is the leading cause. The problem compounds: each undocumented change establishes a precedent, the developer begins resenting unpaid work, quality suffers, the relationship deteriorates. A change order process documents scope evolution and prices it — which is what both parties actually need.
Payment disputes follow a specific failure pattern: project is 80% complete, a deliverable is rejected, payment is withheld, the developer stops working, the project stalls, both parties sue. A well-drafted acceptance process with objective criteria, defined testing periods, and deemed acceptance provisions removes the leverage asymmetry that creates this scenario.
Open source license risk is frequently overlooked. Most custom software is built on open source frameworks, some of which carry GPL or LGPL obligations that can require the entire application to be open-sourced if not managed correctly. The SDA should require disclosure of all open source components and warranty that their use doesn't create contamination issues for the client's proprietary code.
Best Practices
Invest in the specification before signing the SDA. The quality of the specification determines project success more than any other factor including developer quality. Spend 10-20% of the total project budget on specification development — requirements gathering, wireframes, technical architecture, and acceptance criteria. A $200K development project should have a $20-40K specification phase. This investment prevents 10x the cost in disputes and rework.
Use a master SDA plus Statement of Work (SOW) architecture for complex projects. The master SDA governs the ongoing relationship — IP, confidentiality, liability, governing law. Individual SOWs define specific projects or phases. This allows scope, budget, and timeline adjustment for each phase without renegotiating the entire agreement and lets the client evaluate quality before committing to subsequent phases.
Build source code escrow into every critical business application. If the developer goes out of business, gets acquired, or refuses support, the client needs the source code. A third-party escrow agent releases the code on defined trigger events. The annual cost is modest relative to the business continuity value.
Require regular code commits to a shared repository throughout development, not just at delivery. This gives the client access to work in progress and protects them if the relationship breaks down mid-project. Some developers resist this; clients should insist for any project over $50K.
Frequently Asked Questions
Who owns the code in a custom software project?
By default under US copyright law, the developer owns the code — not the client who paid for it. The "work for hire" doctrine applies automatically to employees but not to independent contractors or agencies. Ownership transfers to the client only if the contract includes an explicit written IP assignment. Without this, the client has at best a license to use the software while the developer retains copyright. Every SDA must include an express IP assignment clause.
What should be in the technical specification?
A comprehensive specification covers: functional requirements (what the software does from the user's perspective), technical requirements (architecture, languages, frameworks, performance benchmarks), integration requirements (third-party APIs), security requirements, UI/UX specifications (wireframes or mockups), data model requirements, and acceptance criteria for each feature. For agile projects, a product backlog with story-level acceptance criteria serves this purpose. The specification should be detailed enough to build from and test against without ambiguity.
What is a reasonable warranty period for custom software?
Industry standard is 30-90 days post-acceptance for warranty bug fixes at no charge. The warranty covers defects in conformance with agreed specifications — not general performance dissatisfaction or new feature requests. After the warranty period, ongoing maintenance should be governed by a separate maintenance agreement. Indefinite warranties are unreasonable and developers should firmly resist them.
How should payment be structured?
Milestone-based payments tied to objective deliverables are the standard. A typical structure: 20-30% upfront at signing, 30-40% at agreed mid-project milestones, 30-40% at final acceptance. Avoid purely time-and-materials for fixed-scope projects — it transfers all scope risk to the client and removes developer efficiency incentives. For agile projects, sprint-based payments with acceptance of each sprint provide good cash flow alignment.
What happens if the software doesn't work after delivery?
It depends on what the contract says. If the software doesn't meet the accepted specification and is within the warranty period, the developer fixes it at no charge. If the software meets the specification but doesn't do what the client actually needed, that's a specification problem — potentially the client's responsibility if they approved the spec. If it fails after the warranty period, post-warranty maintenance rates apply. This is why specification clarity and objective acceptance criteria are so critical.