Most people read a software development contract for two things: the price and the deadline. Those matter, but they are the clauses you are least likely to argue about. The ones that cause real trouble only come into play when the relationship ends, because the developer leaves, the budget runs out, or you want someone else to take over.
So read the contract from the end. Ask what you walk away with if the work stopped tomorrow: the code, the rights to it, the access to everything it runs on, and enough documentation for the next developer to start. If the contract does not answer that clearly, nothing else in it will protect you.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
The Short Answer
If you only check five things, check these.
- Ownership: a signed clause assigning all rights in the work to you, effective on payment.
- Pre-existing and open-source code: a permanent licence to anything the developer brings in, and open-source components kept under their own licences.
- Changes: how work outside the original scope is priced and approved, in writing.
- Termination: how either side can end it, and what you pay for work already done.
- Handover: exactly what you receive when it ends, and by when.
This guide covers each, plus the clauses around them. It is general information, not legal advice. For anything large or unusual, a lawyer should read the contract before you sign.
How a Software Development Contract Is Usually Structured
Most software development contracts follow one of two shapes.
A single agreement covers everything, the work, the price and the legal terms, in one document. Common for freelancers and small projects.
A master services agreement plus statements of work. The master agreement holds the legal terms, ownership, confidentiality, liability and termination, and each statement of work describes one piece of work, its price and its deliverables. Common with agencies and longer relationships, because you sign the legal terms once and add work as you go.
The pricing model shapes the rest of the contract. A fixed-price contract needs a tight scope and a change process, because anything outside the scope costs extra. A time-and-materials contract needs rates, caps and reporting. A subscription needs clear terms on what is included and how to pause or cancel. Our guide to outsourcing product development compares those models and who pays when the plan changes under each.
Who Owns the Code
This is the clause that matters most, and the one people most often assume is fine.
US copyright law starts from a simple rule: the person who creates a work owns it. There are two ways for you to end up owning code someone else wrote.
It is a work made for hire. Under 17 U.S.C. section 201(b), the employer or other person for whom a work made for hire was prepared is treated as its author and owns it. For employees, that covers work done within the scope of the job. For independent contractors, the Copyright Office's Circular 30 explains that a commissioned work only qualifies if it falls into one of nine categories, such as a contribution to a collective work, a compilation or a translation, and both sides sign a written agreement saying so. Software is not on that list. The label does not settle who is an employee either. In Community for Creative Non-Violence v. Reid, the Supreme Court held that it depends on the general common law of agency, weighing factors such as the right to control how the work is done, the source of the tools, the method of payment, employee benefits and tax treatment, with no single factor deciding it.
It is assigned to you. Under 17 U.S.C. section 204(a), a transfer of copyright ownership "is not valid unless" it is in writing and signed by the owner of the rights or their authorized agent. That is why the assignment clause matters so much. For a contractor writing software, it is usually the only route to ownership.
What to look for: a clause stating that all rights in the work created for you are assigned to you, signed by the developer or their company. Many contracts make the transfer effective on payment, which is fair to both sides. What you should not accept is silence, or a clause that gives you only a licence to use the code while the developer keeps ownership.
Contracts sometimes combine the two, calling the work a work made for hire and adding an assignment as a backup. In California, that label can have side effects. Labor Code section 3351.5(c) includes as an "employee" any person engaged by contract to create a commissioned work under a signed agreement that it is a work made for hire, where the commissioning party obtains all the copyright. Unemployment Insurance Code section 686 makes the commissioning party the "employer" of the author for unemployment insurance purposes. If either side is in California, ask a lawyer whether a plain assignment suits you better.
Code the Developer Already Had, and Open-Source Code
Almost no software is written from nothing. Developers reuse their own libraries and snippets, and nearly every project depends on open-source packages. A good contract deals with both.
Pre-existing code. The developer usually keeps ownership of tools and code they wrote before working with you, which is reasonable, since they will use them again. What you need is a permanent, irrevocable, free licence to use and modify any of it that ends up in your product. Without that, part of your product could belong to someone you no longer work with.
Open-source code. Open-source packages stay under their own licences, and you cannot be assigned ownership of them. Most common licences are permissive and easy to live with. Strong copyleft licences are different. The GNU project's FAQ says that if you add a module to a GPL-covered program, "the whole combined program has to be released under the GPL." Ask the developer to list significant open-source dependencies and to flag any copyleft licences before using them.
AI-Written Code
In 2026 most developers use AI coding tools, and a contract written a few years ago probably says nothing about it.
The US Copyright Office addressed this in January 2025, in Part 2 of its report on copyright and artificial intelligence. It concluded that "copyright does not extend to purely AI-generated material, or material where there is insufficient human control over the expressive elements." It also said human authors keep copyright in their own contributions that are perceptible in AI output, and in "the creative selection, coordination, or arrangement of material in the outputs, or creative modifications of the outputs."
For a software project, that means code produced entirely by an AI tool may not be protected by copyright at all, while code a developer meaningfully writes, selects or modifies can be. An assignment clause can only transfer rights that exist.
None of this means you should ban AI tools. It means the contract should say three things: whether AI tools may be used, that the developer reviews, tests and takes responsibility for everything they deliver whoever or whatever wrote it, and that whatever rights exist in the work are assigned to you.
Scope, Acceptance and Payment
These are the clauses everyone reads, so a few notes on reading them well.
Scope. Describe the problem and the outcome, not just a list of screens. A scope that is too detailed becomes a fight about whether a change is in or out. One that is too vague cannot be accepted.
Acceptance. Say how you will decide the work is done: a review period, a list of criteria, and what happens if you find problems. Without it, payment and disputes both drift.
Payment. Tie payment to delivered, working software where you can, milestones for fixed price, regular invoices with a cap for hourly work. On Upwork, for example, the Optional Service Contract Terms apply unless the two sides agree otherwise, and they say that once the freelancer receives full payment, the work product and its intellectual property become the client's, except for the freelancer's background technology, which the client receives a licence to use. Ownership that transfers on payment is a fair pattern for both sides.
Changes. Every software project changes. Agree in advance how a change is requested, priced and approved, and that nothing outside scope is billed without your written approval.
Want terms where the code is yours by default?
A senior developer on subscription: $849 a month, as many requests as you like, most shipped within 48 to 72 hours, and your money back if the first 7 days don’t prove it.
Termination and Handover
This is where reading from the end pays off.
Termination. Either side should be able to end the contract with reasonable notice. Check what you owe when it ends: usually payment for work completed up to that point, and nothing for work not yet started. Be wary of long notice periods, minimum terms or kill fees that make leaving expensive.
Handover. List exactly what you receive, and set a deadline for it. The checklist below is a good minimum.
What the handover clause should list
- The complete source code, in a repository in your account, including anything not yet merged.
- Access to every account the developer set up for the project: hosting, databases, domains, email services, payment providers and app stores, transferred to you or registered to you from the start.
- Passwords, API keys and other secrets, handed over and then rotated.
- Documentation on how to install, run, test and deploy the project, and any known issues.
- Design files and other assets created for the project.
- A short period of reasonable cooperation, so the next developer can ask questions.
The cheapest handover is the one that never needs to happen. If the repository and accounts are in your name from day one, ending the contract is a matter of removing access rather than recovering it.
The Other Clauses
These matter less often, but check that each is there and reasonable.
Confidentiality
Both sides keep each other's confidential information private, during the contract and after it ends. Your customer data, plans and code should be covered explicitly.
Warranties
Usually a promise that the work will be done competently and will not knowingly infringe anyone else's rights. Some contracts add a short period in which defects are fixed at no extra cost.
Limitation of liability
A cap on how much either side can claim, often tied to the fees paid over a period. It is normal. Check that the cap is not so low it makes the other promises meaningless.
Non-solicitation
A promise not to hire each other's staff for a period. Common with agencies. Check it does not stop you hiring the developer directly if you both want that later.
Portfolio use
Whether the developer can show your project publicly. If you are building something not yet announced, say no or require written permission.
Governing law and disputes
Which state's law applies and how disputes are resolved. Prefer your own state where you can.
Red Flags Before You Sign
Template or Lawyer
A reputable template is a sensible start. Read every clause, and check ownership, pre-existing code, handover and termination against this guide before you sign.
Most firms have standard terms. Read them for the clauses in this guide, ask for changes where they fall short, and walk away if ownership or handover will not move.
The cost of a review is small next to the cost of a dispute about who owns your product. Bring this checklist so the review starts from what matters.
How We Handle This
We sell a product development subscription, so here is how our own terms answer the questions in this guide, as a worked example rather than a pitch.
The code goes into your repository from the first commit. Once the billing period in which work was delivered has been paid for, all rights in the work created specifically for you transfer to you. We keep our general know-how and any code we wrote before working with you or independently of you, and where that ends up in your project, you get a permanent, free licence to use and modify it. Open-source components stay under their own licences. There is no minimum term: you can pause at any time, or cancel at any time with no notice period, effective at the end of the current billing period. When you cancel, we remove our access to your systems and delete the credentials you gave us. The full wording is in our terms.
The Bottom Line
A software development contract is mostly read at the beginning and mostly matters at the end. Price and deadline are what you negotiate. Ownership, pre-existing code, handover and termination are what decide whether you can keep going without the person who wrote the code.
So before you sign, ask one question of every clause: if this relationship ended tomorrow, what would I walk away with? If the answer is the code, the rights, the access and the documentation, the contract is doing its job.
