Software Development Agreement: What To Include Before You Sign
What A Software Development Agreement Covers
A software development agreement is a written contract between a business and the developer or agency that builds its software. It states what will be built, the price and schedule, who owns the result, how the work is accepted and what happens if the project ends early. It replaces assumptions with terms both sides have signed.
Most disputes over custom software start with something nobody wrote down: whether a change was in scope, who owns the code, or when the work counted as finished. This guide goes through the clauses one at a time, in plain language, and says what to ask for and what to watch for. It is written for business owners and managers, and it assumes no legal background.
This guide is general information for US businesses, not legal advice. Contract law and ownership rules vary by country and state, so have a lawyer review the final agreement before you sign. The aim here is to help you walk into that review knowing what matters. If you are still choosing a developer, start with our guide to choosing a custom software development partner.
What Is A Software Development Agreement?
A software development agreement is the main contract that governs a custom software project. It can be one document or a set, such as a master agreement for the legal terms plus a statement of work for each project's scope, price and schedule. A separate non-disclosure agreement and a maintenance agreement often sit alongside it.
You may also see it called a software development contract, a software development services agreement or a custom software development agreement. The names differ, but the job is the same: to record what both sides have agreed, so that a disagreement later can be settled by reading the page and not by arguing about memory. Table 1 explains the documents that often travel together.
| Document | What it does |
|---|---|
| Software development agreement | Sets the main terms: the work, price, ownership, acceptance, confidentiality, liability and how the relationship ends. |
| Statement of work (SOW) | Describes the scope, deliverables, schedule and price for one project. Often attached to the agreement. |
| Master services agreement (MSA) | Holds the general legal terms for several projects, so each new project needs only a new statement of work. |
| Non-disclosure agreement (NDA) | Covers confidentiality only. Often signed before the project is described in detail. |
| Maintenance agreement | Covers support, fixes and hosting after launch. |
Table 1: The documents that often make up a software development agreement.
For a small project, one agreement with the scope attached may be enough. For a larger or ongoing relationship, separate documents keep the legal terms stable while the scope changes.
Who Owns The Code You Pay For?
Paying for software does not automatically make you its legal owner. Under US copyright law, the person who writes code is generally its author, and a business that commissions software from an outside developer usually becomes the owner only through a signed written transfer. Ask for an assignment of all rights in the work created for you.
The US Copyright Office explains that a commissioned work by an independent contractor counts as a work made for hire, which would make the client the owner, only if it falls into one of nine listed categories and the parties sign a written agreement saying so (US Copyright Office, Circular 30 (opens in a new tab)). Software is not among the nine categories. A transfer of copyright ownership, by contrast, must be in writing and signed (17 U.S.C. 204 (opens in a new tab)). In practice, that means the agreement itself has to say that the rights in the finished work move to you.
This guide covers outside developers and agencies. If the person writing your code is your own employee, different rules apply, and a lawyer can explain them. Figure 2 shows how ownership follows what is signed.
Who Owns Commissioned Code?
Ownership has three parts worth separating in the agreement.
The work made for you. Ask for an assignment, which is a written transfer of all rights in the code, designs and documents created for your project. Ask when it takes effect: on creation or on payment.
The developer's existing tools. Most developers reuse their own libraries and tools. These stay theirs, so ask for a permanent, irrevocable license to use them with what they built for you, at no extra fee.
Third-party and open-source parts. Modern software includes components that other people wrote and license on their own terms. Ask for a list of them and their licenses, so you know what you can change, sell or share.
If the developer uses AI coding tools, the question gets another layer. In January 2025 the US Copyright Office concluded that material generated entirely by AI is not copyrightable, while human-authored expression, and creative selection or arrangement of AI output, can be protected (US Copyright Office, Copyright and Artificial Intelligence, Part 2 (opens in a new tab)). Ask the developer to tell you whether AI tools are used and how the code is reviewed. Our guide to writing an AI acceptable use policy covers the rules for your own team's use of AI tools.
What To Include In A Software Development Agreement
The twelve sections below follow the order of a typical agreement. For each one, the text says what the clause does, what to ask for and what to watch for. Ownership has its own section above, so it is not repeated here.
1. The Parties And The Work
Name both legal entities exactly, and describe the work in terms of what the software must do for the business, not only a feature list. Attach the scope document and say that it forms part of the agreement. "As discussed" is not a scope. Ask for exclusions in writing too, such as "no mobile app in this phase", because what is left out causes as many disputes as what is put in.
2. Deliverables, Milestones And Schedule
List each deliverable, such as designs, a working first release, documentation and training, with a date or a time range for each. Tie dates to milestones you can check, not to vague phrases like "soon after approval". Say what each side must supply to keep the schedule, such as feedback within an agreed number of days. Our guide to the custom software development timeline explains what usually moves the dates.
3. Price And Payment
State the price model, whether fixed price or time and materials, and what the price includes and excludes. Tie payments to milestones, not to calendar dates, and keep a final share until the work is accepted. For hourly work, ask for rates by role, an estimate, a cap and a weekly report of hours. Say who approves expenses before they are incurred, and when invoices are due.
4. Changes To The Scope
Scope will change, so agree the process before it does. A workable process has the developer describe the change, price it and show the effect on the schedule, and you approve it in writing before work starts. Without this clause, changes tend to be argued about after the work is done.
5. Acceptance And Testing
Acceptance is the moment the work counts as delivered, and often the moment a payment falls due. Write down the acceptance criteria, the length of the test period and what happens when you find defects. Figure 3 shows a simple acceptance process. Watch for clauses that treat silence as acceptance after a very short period, because they leave no time to test properly.
How Acceptance Works
6. Confidentiality And Data Protection
Confidentiality should cover your business information, customer data and anything shared during the project, and should last beyond the end of the agreement. If the software will handle personal or sensitive data, add security responsibilities, where data is stored, who on the developer's team can see it and how breaches are reported. For AI work, our guide to how to vet an AI vendor lists the claims to check. SensViz also explains why data handling commitments belong in writing (opens in a new tab), since an NDA alone does not cover them.
7. Warranties And Bug Fixes
A warranty is a promise about the work. Ask the developer to promise that the work will meet the agreed specification, that it does not copy anyone else's code without permission, and that they have the right to hand it over. Ask for a bug-fix period after acceptance, during which defects in the agreed scope are fixed at no charge, and write down how long it lasts.
8. Liability And Indemnity
Two terms matter here. A limitation of liability caps how much one side can owe the other if something goes wrong. An indemnity is a promise to cover the costs if a third party makes a claim, for example that the code infringes their copyright. Both are legal terms with real consequences, so this is where a lawyer's review earns its fee. Check that the caps and promises are reasonably balanced and that you understand what they mean in dollars.
9. Support After Launch
The build agreement should say what happens when the software goes live: who hosts it, who fixes problems, how fast they respond and what it costs. Many teams leave this to a separate maintenance agreement, which is fine, as long as the build agreement says so and the two documents do not contradict each other. Our overview of software maintenance contracts explains what they usually cover. To see what to budget, read our guide to software maintenance cost after launch.
10. Source Code, Handover And Escrow
Ask for the code to live in a repository your business controls, with hosting, domain and other accounts registered in your name. Ask for handover documents that let another developer take over: how the system is set up, deployed and backed up. Where a developer licenses software instead of transferring it, source code escrow can help. Escrow means a neutral third party holds a copy of the code and releases it to you if the developer stops supporting it.
11. Ending The Agreement
Say how either side can end the agreement, with how much notice, and what happens next. Ask to pay only for work done, to receive all work in progress, and to get a defined period of handover help. Separate ending for convenience, where nobody has done anything wrong, from ending for cause, such as missed milestones, and say how much time the developer gets to fix a problem before you can end the agreement.
12. Disputes And Governing Law
Choose which state or country's law applies, and where disputes will be handled. Agree the steps before anyone sues: a meeting between named people, then mediation, then arbitration or court. Check for automatic renewal and for clauses that limit you from working with other developers. A lawyer should set these terms for your situation.
Should You Use A Software Development Agreement Template?
A software development agreement template is a useful starting point, but it is not a finished contract. Templates leave blanks for scope, price and dates, and they cannot know your risks. Use one to learn the structure, then have a lawyer adapt it to your project and your state before anyone signs.
A software development contract template is also a quick way to see what a full agreement contains. Some templates and checklists are thin on the points that cause the most trouble: how the work is accepted, what happens to the code if the relationship ends, how long confidentiality lasts and how data is protected. Check any template against the twelve sections above, and fill the gaps before you sign.
Red Flags In A Draft Agreement
These are the clauses that most often work against the buyer. Raise each one with the developer and your lawyer.
The developer keeps all rights and licenses the code back to you. You would not own what you paid for, and changing developers could require their permission.
No acceptance criteria. Without them, "finished" means whatever the developer says.
Most of the price is due up front, or all of it on launch. Payments should follow milestones, with a share held until acceptance.
Scope described as "as discussed" or "per conversation". If it is not written down, it is not agreed.
Nothing about source code, accounts or documentation. Handover then depends on goodwill.
Automatic renewal, or a long notice period to end. You could be locked in after the work is done.
Subcontractors allowed without notice. You should know who has your data and your code.
No mention of AI tools. Ask whether they are used and how the output is checked.
How To Review A Draft Before You Sign
You do not need to read a draft like a lawyer to review it usefully. These five steps help you find the gaps before your lawyer does, which saves time and fees.
Read it with the scope document beside it. Check that every deliverable, date and exclusion in the scope appears in the agreement or is attached to it.
Mark every place that says who decides. Phrases such as "at the developer's discretion" or "as reasonably determined" deserve a question.
Check the items behind most disputes. Ownership, acceptance, payment, changes, handover and exit. If any one is missing, ask for it.
Ask the developer to explain anything unclear in writing. A written answer can be attached to the agreement or referred to later.
Send it to a lawyer with your list. Include the scope document and your marked questions.
Questions worth bringing to your lawyer include:
Does the ownership clause transfer everything, and when does the transfer take effect?
Are the liability limits and indemnities balanced between the two sides?
Which state's law applies, and where would a dispute be heard?
Are there automatic renewals, exclusivity terms or limits on hiring the developer's staff?
Are subcontractors, offshore teams and AI tools covered by the confidentiality and ownership terms?
Do AI Projects Need Different Terms?
AI projects add terms that ordinary software agreements often skip. Ask which AI providers and models are used, where your data goes, whether any provider can keep it or train on it, how accuracy will be tested on your real data and who is responsible when the system gets something wrong. Ask for access to evaluation data and deployment accounts, not only the code.
A short paid pilot, covered by its own small agreement, lets you test those answers before you commit to the full build. Our guide to running an AI proof of concept explains how. For the questions to ask the vendor, see our guide to choosing an AI vendor.
A Worked Example: A Property Manager Reviews A Draft (Illustrative)
This example is hypothetical, and the terms are invented to show what a review can catch.
A property management company with 40 staff wants a portal where tenants can submit repair requests. An agency sends a draft agreement. The owner reads it beside the scope document, as in step 1 above, and marks five problems before sending it to her lawyer. Table 2 shows what she found and what she asks for.
| The draft says | Why it matters | What she asks for |
|---|---|---|
| The developer owns all code and grants the company a license to use it. | The company would not own the portal and could not freely move to another developer. | An assignment of rights in the work made for her, plus a license to the agency's existing tools. |
| Work is accepted if the company does not object within two days of delivery. | Two days is too short to test, and silence counts as approval. | Written acceptance criteria and an agreed test period. |
| The final payment is due on launch day. | The company has no leverage if bugs appear after launch. | A final share held until acceptance and the end of the bug-fix period. |
| The draft does not mention source code or hosting accounts. | Handover would depend on goodwill. | Code in a repository the company controls, accounts in its name, and handover documents. |
| Either side may end it on seven days' notice, with nothing on work in progress. | Ending could leave the company with paid-for work it cannot use. | Payment only for work done, and delivery of all work in progress. |
Table 2: An illustrative draft review. The agency, terms and numbers are invented.
The agency agrees to most of the changes after a call. The owner now has a draft that matches what both sides said they wanted, and her lawyer starts from a better document.
How Fossilite Approaches Agreements
We would rather agree the scope, the acceptance checks and who owns what in plain language before any contract is drafted, so the legal document reflects what both sides already understand. We suggest that every client has a lawyer review the final agreement, and we also check whether an existing tool or a simpler change would solve the problem before recommending custom software or AI.
Frequently Asked Questions
These are the questions buyers ask most often about a software development agreement. Each answer stands on its own.
Do I Need A Written Software Development Agreement For A Small Project?
Yes. Even a small project benefits from a short written agreement covering scope, price, ownership, acceptance and how either side can end it. A one-page agreement with the scope attached is far better than an email thread. Ownership alone justifies the paper, because a transfer of copyright generally has to be in a signed writing.
What Is The Difference Between A Software Development Agreement And A Statement Of Work?
The agreement sets the general legal terms, such as ownership, confidentiality, liability and termination. A statement of work describes one project: its scope, deliverables, schedule and price. Many projects use both, with the statement of work attached to the agreement. For a small project, a single document can combine them.
What Is Source Code Escrow?
Source code escrow is an arrangement where a neutral third party holds a copy of the software's source code and releases it to you under agreed conditions, such as the developer going out of business or ending support. It matters most when the developer licenses its own software to you instead of transferring the code.
What Happens If The Developer Misses Deadlines?
The agreement decides. Good agreements tie dates to milestones, require the developer to give notice of delay, allow a set period to fix the problem and let you end the agreement if it is not fixed. Without those terms, a missed date may have no consequence beyond an argument. Ask a lawyer how to word the remedies.
Can I End A Software Development Agreement Early?
Only as the agreement allows. Look for the notice period, whether you can end it without a reason and what you owe. A fair clause lets you pay only for work done, receive all work in progress and get handover help. Ending because the developer failed to perform often needs a written warning first.
Who Is Responsible For Bugs After Delivery?
It depends on the warranty and bug-fix terms. Many agreements make the developer fix defects in the agreed scope for a set period after acceptance at no extra charge, then move to a maintenance agreement. Write the period down, define what counts as a defect and say how quickly the developer must respond.
Who Owns The Code If The Developer Used AI Tools?
Ownership still depends on the agreement, but AI adds a limit. The US Copyright Office has concluded that material generated entirely by AI is not copyrightable, though human-authored expression and creative selection or arrangement can be protected. Ask the developer to disclose AI tool use and explain how the code is reviewed and changed.
Once the build agreement is settled, the next document is the support agreement. Our overview of software maintenance contracts explains what support agreements usually cover and how they are priced.