A software development agreement sets out who builds what, by when, for how much, and, most importantly, who owns the finished code. That last point is where companies lose the most: paying for software does not automatically make you the owner of it. This guide shows you what the agreement must include, how scope, milestones, and acceptance fit together, the intellectual-property trap that catches almost everyone, and gives you a clear structure you can copy.
The short answer
A software development agreement defines the scope, deliverables, timeline, payment, acceptance criteria, warranties, confidentiality, and the ownership of the code. The clause that matters most is intellectual property: under U.S. copyright law, code written by an independent contractor belongs to the contractor by default, and software cannot be made a "work made for hire" just by saying so. To own what you paid for, the agreement needs an express copyright assignment. Use milestones tied to staged payments and clear acceptance tests, and pick a pricing model (fixed price, time and materials, or milestone-based) that matches the project's certainty.
This article is general information for a U.S. audience, not legal advice, and the rules vary by state and by project. For a high-value build or a dispute, have a technology attorney review the agreement.
Need the agreement today?
AI Lawyer drafts a clean, ready-to-sign software development agreement from a few questions: parties, scope, milestones, payment, and an IP-assignment clause. Free to try, no credit card.
Draft my agreement →
Assignmentyou own contractor code only with a written copyright assignment
Milestonestie staged payments to accepted deliverables
Acceptancedefine the test, the fix window, and what failure means
"We paid"paying for code does not, by itself, make you its owner
You might also like:
- App Development Agreement Template (Free)
- AI Contract Review Software: What It Does
- Business Requirements Document (BRD): The Guide-the-legal-strategic-must-have-for-2025-projects)
What is a software development agreement?
A software development agreement is a contract between a client and a developer (a freelancer, an agency, or a vendor) that defines the software to be built, the timeline, the payment, and the legal terms, including who owns the resulting code. It turns a project brief into an enforceable deal with clear scope, acceptance criteria, and remedies if either side fails to perform.
The agreement does three jobs at once. It defines the work so both sides share one definition of "done," it sets the money against milestones, and it settles ownership and risk before any code is written. Skipping the third job is what turns a successful build into a legal fight.
When do you need one, and who benefits most?
Use a software development agreement any time you hire an outside developer or agency, or take on client work as one. It matters most for custom builds, milestone projects, anything involving sensitive data or valuable IP, and any engagement large enough that you would want to enforce it. Both sides benefit: the client gets defined deliverables and ownership, the developer gets a clear scope and a payment schedule.
Typical situations:
- A startup hires a freelancer or agency to build its product.
- A company commissions custom software, an app, or an integration.
- A developer or studio takes on client work and wants scope and payment locked.
- A project involves confidential data, third-party code, or regulated information.
The bigger the build and the more valuable the code, the more the agreement is worth.
What should a software development agreement include?
A solid agreement names the parties, defines the scope and deliverables (usually in an attached specification), sets the milestones and timeline, fixes the payment terms, defines acceptance testing, assigns intellectual-property ownership, and covers warranties, confidentiality, indemnification, and termination. The scope and the IP clause carry the most weight.
| Clause | What it should say |
|---|---|
| Parties | Full legal names of the client and the developer or agency |
| Scope and deliverables | The software to build, referenced to an attached specification |
| Milestones and timeline | Phases, interim deliverables, deadlines, and the final date |
| Payment | The amount, the model, and how payments tie to milestones |
| Acceptance and testing | The test criteria, the fix window, and what failure triggers |
| IP ownership | An express assignment of the code and related IP to the client |
| Warranties | That the work is original and will perform as specified |
| Confidentiality | Protection of each side's confidential information |
| Indemnification | Who covers third-party IP claims, and the liability cap |
| Termination | How either side can exit, and what happens to work in progress |
The clause people skip is acceptance, and the one they get wrong is IP ownership. Both are covered below.
Who owns the code? The work-made-for-hire myth
Paying for software does not make you its owner. Under U.S. copyright law (17 U.S.C. §201), code written by an independent contractor belongs to the contractor by default. "Work made for hire" generally covers employees, and commissioned software is not one of the nine categories that can be made a work for hire by agreement. To actually own what you paid for, the contract must include an express written copyright assignment from the developer to the client.
This is the single most expensive misunderstanding in software contracts. A client assumes that because they funded the build, they own it. But absent an assignment, the developer holds the copyright and the client has, at best, an implied license to use it, which is far weaker than ownership.
The Supreme Court drew this line in Community for Creative Non-Violence v. Reid (1989), using common-law agency factors to separate employees from independent contractors. The practical takeaways for a software agreement:
- An employee's code is generally a work made for hire, so the employer owns it.
- An independent contractor's code is not a work made for hire by default, and software is not an eligible commissioned category, so a "work made for hire" label alone does not transfer it.
- The reliable fix is an express assignment: the developer "assigns all right, title, and interest" in the deliverables to the client, often effective on full payment.
Two modern wrinkles to address in the clause: third-party and open-source components (which the developer licenses, not assigns, so the agreement should require disclosure and compatible licenses), and AI-assisted code (clarify ownership and that the developer is responsible for what their tools produce).
How do scope, milestones, acceptance, and payment fit together?
Scope defines what gets built, milestones break it into phases with deadlines, acceptance tests confirm each phase meets the criteria, and payment is released as milestones are accepted. Tying payment to accepted milestones is what protects both sides: the developer gets steady cash flow, and the client pays for work only after it passes the test.
| Element | What good looks like |
|---|---|
| Scope | A detailed specification attached as an exhibit, not a one-line brief |
| Milestones | Phases with a deliverable, a deadline, and acceptance criteria each |
| Acceptance | A defined test, a defect-reporting process, and a fix window |
| Change orders | A written process to price and approve scope changes |
| Payment | Released per accepted milestone, with a final holdback on acceptance |
A change-order process matters as much as the original scope. Most disputes are not about the first spec; they are about the changes nobody priced.
Fixed price, time and materials, or milestone-based?
Choose the pricing model that matches how certain the scope is. Fixed price suits a well-defined build and shifts overrun risk to the developer. Time and materials suits an evolving scope and shifts risk to the client. Milestone-based pricing sits in between, releasing set amounts as defined phases are accepted, and is the most common choice for custom software.
| Model | Use it when | Who carries the overrun risk |
|---|---|---|
| Fixed price | The scope is well defined and stable | The developer |
| Time and materials | The scope is uncertain or will evolve | The client |
| Milestone-based | The project breaks into clear phases | Shared, phase by phase |
Whatever the model, write it into the payment clause and tie it to the milestones and acceptance tests so there is no gap between "delivered" and "paid."
The clauses most agreements miss
Beyond scope and IP, the clauses that prevent the worst disputes are source-code escrow, an open-source and third-party components clause, a clear warranty and its duration, an indemnification and liability cap, and confidentiality. These rarely matter until something goes wrong, and then they matter more than anything.
- Source-code escrow: who holds the code and when the client can access it, useful if the vendor disappears.
- Open-source and third-party components: the developer discloses them and warrants license compatibility.
- AI-assisted code: ownership is clear and the developer stands behind what their tools generate.
- Warranty: the software will conform to the spec for a defined period, with a remedy if it does not.
- Indemnification and a liability cap: who covers a third-party IP claim, and the ceiling on damages.
Common mistakes to avoid
The mistakes that sink software projects are predictable: no written agreement, a vague scope, no IP assignment (so the client never owns the code), no acceptance criteria, and no change-order process. Each one converts a delivery problem into a legal one.
- Starting work on a purchase order or email thread with no real agreement.
- Writing a one-line scope instead of an attached, detailed specification.
- Relying on "work made for hire" language instead of an express IP assignment.
- Leaving acceptance undefined, so "done" is whatever each side wants it to mean.
- Having no written change-order process, so every change becomes a fight.
Frequently asked questions
Who owns the code in a software development agreement?
Whoever the agreement says, and by default that is the independent contractor who wrote it. Under U.S. copyright law, paying for the work does not transfer ownership. The client owns the code only if the developer signs an express copyright assignment, which the agreement should include, often effective on full payment.
Is software a "work made for hire"?
Generally only when an employee writes it within their job. Code from an independent contractor is not a work made for hire by default, and software is not one of the nine categories that can be made a work for hire by agreement. So a "work made for hire" label does not reliably transfer contractor code; an assignment does.
What is the difference between an assignment and a license?
An assignment transfers ownership of the copyright to the client. A license only grants permission to use the code while the developer keeps ownership. If you want to control, resell, or freely modify the software, you need an assignment, not a license.
What should the scope section contain?
A detailed specification of the software to be built, attached as an exhibit rather than summarized in a sentence. It should list features, deliverables, and the acceptance criteria for each, and connect to the milestone and timeline schedule. A vague scope is the root of most disputes.
How should payments be structured?
Tie payments to milestones that have passed acceptance testing, with a final holdback released on full acceptance. This gives the developer cash flow and gives the client assurance that they pay for work only after it meets the agreed criteria. Match the model (fixed, time-and-materials, or milestone) to how certain the scope is.
What is acceptance testing?
A defined process where the client checks each deliverable against the agreed criteria, reports defects, and the developer fixes them within a set window. The agreement should say how many rounds of testing apply and what happens if the software keeps failing, including a right to terminate.
What is source-code escrow and do I need it?
It is an arrangement where a neutral third party holds the source code and releases it to the client on defined triggers, such as the vendor going out of business. It is worth it when you depend on software a vendor hosts or maintains and you would be stranded without the code.
Do I need a lawyer for a software development agreement?
For a small, low-risk project a solid template can be enough. For a valuable build, sensitive data, or a complex IP and indemnification setup, a technology attorney is worth a review, especially of the assignment, warranty, and liability-cap clauses. An AI tool can produce a strong first draft to review.
Sources and references
- 17 U.S.C. §201, Ownership of copyright, and the work-made-for-hire definition (Cornell LII).
- Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989), on employee vs independent-contractor authorship.
- U.S. Copyright Office guidance on works made for hire and the nine eligible commissioned categories.
Own what you build
Draft a software development agreement that actually transfers the code.
AI Lawyer builds a ready-to-sign agreement from a few questions, with the scope, milestones, acceptance tests, and an express IP-assignment clause set for your project. Free to start, no credit card required.
Start free with AI Lawyer →