If you hire an agency or freelancer to build software or a website, do not assume you own the code because you paid for it. In the United States, the developer who writes the code usually owns the copyright unless a written agreement says otherwise. A good software development contract settles that question in writing, and it also covers scope, payment, acceptance, access to the source code, who holds the domain and hosting accounts, support after launch, and how the project gets handed over if the relationship ends.
This is general information, not legal advice. Laws vary by state and country, and every project is different. Have an attorney review any software development contract before you sign it.
What Is a Software Development Contract?
A software development contract is the agreement between your business and the agency or freelancer who builds your website, web app, or custom system. It usually comes in two parts: a master services agreement with the legal terms (ownership, liability, confidentiality, termination) and a statement of work (SOW) that describes this specific project: what gets built, by when, and for how much.
The contract matters most when something goes wrong. If the project runs late, the budget runs out, or you decide to switch developers, the contract is what tells everyone who owns what and what happens next. Writing it when everyone is still friendly is much easier than negotiating it in the middle of a dispute.
Who Owns the Code When You Hire a Developer?
Under US copyright law, the person who creates a work generally owns it. When an employee writes code as part of their job, the employer is typically the owner. When an outside agency or freelancer writes it, the default is different: in many cases the developer keeps the copyright unless there is a written agreement transferring it.
You will often see the phrase "work made for hire" in contracts. For independent contractors, that label only applies to certain categories of commissioned work and requires a written agreement, and custom software does not always fit neatly into those categories. For that reason, many contracts include a work made for hire clause and, as a backup, a written assignment of copyright that transfers ownership to the client. A copyright assignment generally has to be in writing and signed to be effective, so a handshake or an invoice marked "paid" is not enough.
Assignment vs License: What Is the Difference?
There are two common ways a contract can give you rights to the code:
- Assignment: ownership of the code transfers to your company. You can modify it, hire another developer to maintain it, or sell it with your business.
- License: the developer keeps ownership and gives you permission to use the code. A license can be broad (perpetual, irrevocable, allowing modification and transfer) or narrow (limited to one use, tied to an ongoing payment, revocable).
Both can be fair. Agencies that reuse their own frameworks often license those parts and assign the rest. What matters is that the contract says which one applies, to which parts of the code, and what you are allowed to do with it. A contract that says the agency owns the code and says nothing about your license leaves you exposed.
Background IP and Open-Source Components
Almost no software is written from scratch. Your project will likely include the developer's pre-existing tools and code (often called background IP) and open-source libraries. A clear contract:
- Lists or describes the background IP and grants you a license to use it as part of your software, ideally perpetual and transferable with your business.
- Confirms that open-source components are used under their own licenses and that those licenses are compatible with how you plan to use or sell the software.
- Covers third-party paid services (plugins, APIs, themes) and states whose name the subscriptions are in.
What Should a Software Development Contract Include?
These are the clauses worth reading closely, whether you are building a marketing site or a full system like a custom CRM.
Scope, Deliverables and Acceptance
- Scope or statement of work: the features, pages, integrations, and platforms included, and just as important, what is not included.
- Deliverables: the working software, the source code, documentation, design files, and credentials you receive.
- Acceptance: how you test and approve each deliverable, how long you have to review it, and what happens if it does not meet the agreed requirements.
Milestones, Payment and Change Requests
- Milestones and payment: payments tied to delivered, accepted work rather than to dates alone.
- Change requests: a simple written process for new ideas mid-project, with the cost and timeline impact approved before work starts. Scope changes are normal; surprise invoices should not be.
Ownership, Code and Data
- IP ownership: assignment or license, when it takes effect (often on final payment), and how background IP is handled.
- Source code and repository access: the code lives in a repository (for example on GitHub or GitLab) that your company owns or can access at any time, not only at the end.
- Accounts in your name: domain, hosting, cloud services, app store accounts, analytics, and email sending services registered to your business, with the developer added as a user.
- Data ownership and export: your data belongs to you, and you can export it in a standard format.
- Confidentiality: both sides protect each other's confidential information, including your customer data and business processes.
Warranty, Support and Maintenance
- Warranty or bug-fix period: a defined period after launch (commonly 30 to 90 days) when defects in the agreed scope are fixed at no extra cost.
- Maintenance and support: what ongoing care includes (updates, security patches, backups, small changes), response times in a service level agreement (SLA), and how it is billed. This is often a separate agreement.
Termination, Handover and Disputes
- Termination: how either side can end the contract, with what notice, and what you pay for work already done.
- Handover: on termination or at the end of the project, the developer delivers the latest code, database, credentials, and documentation within a set number of days.
- Dispute resolution: which state's law applies, where disputes are handled, and whether mediation or arbitration comes before a lawsuit.
Fixed Price vs Time and Materials: Which Is Better?
The pricing model shapes how scope, risk, and change requests work in practice. None is better in every case.
| Factor | Fixed price | Time and materials | Retainer |
|---|---|---|---|
| How it works | One agreed price for a defined scope | You pay for the hours actually worked at agreed rates | A set monthly fee for a block of hours or an ongoing service |
| Best for | Clear, stable scope: a website, a well-defined first version | Evolving products, discovery, integrations with unknowns | Maintenance, ongoing improvements, continuous marketing or SEO work |
| Budget predictability | High, as long as scope does not change | Lower; use estimates, caps, and regular reports | High per month |
| Flexibility | Low; changes go through change requests | High; priorities can shift sprint by sprint | Medium; work is prioritized within the monthly hours |
| Who carries the risk | Mostly the developer, who may pad the price to cover it | Mostly the client | Shared; unused hours may or may not roll over |
| What to watch | Vague scope that leads to disputes over what is "included" | No cap and no visibility into hours | Unclear deliverables and rollover terms |
Many projects mix models: a fixed-price discovery phase, then fixed-price or time and materials development, then a retainer for maintenance. For a sense of how budgets are built, see our guide to how much custom software costs. If you are not yet sure whether you need a site or an application, read web app vs website first, since the answer changes the scope and the contract.
Who Should Own the Domain, Hosting and Accounts?
Website ownership is about more than the code. If the agency registers your domain in its own name, you may not be able to move your website or even your email without its cooperation. The same goes for hosting, Google Analytics, Google Business Profile, Search Console, payment processors, and app store accounts.
The safe pattern is simple: every account is registered to your business, with an email address your company controls, and the developer gets user or admin access. If an agency manages hosting for you, the contract should say that the site files, database, and backups are yours and will be delivered on request. This applies equally to a website design project and to a large application.
What Are the Red Flags in a Software Development Contract?
- The agency holds your domain in its own name or account, with no clause to transfer it.
- No repository access until the end of the project, or never.
- Vague scope, such as "a modern website with all needed features," with no list of deliverables.
- "We own the code" with no license describing what you can do with it.
- No handover clause, so there is no obligation to deliver code, data, and credentials if you leave.
- Payments not tied to milestones, or most of the budget paid upfront.
- No acceptance criteria, so "done" is whatever the developer says it is.
- No warranty period, meaning bugs found the week after launch are billed as new work.
- Your data can only be exported for a fee or in a proprietary format.
A red flag does not always mean bad intent. Sometimes it is just a template nobody updated. Ask about it, and get the answer added to the contract in writing.
Software Development Contract Checklist
Use this list when you review a proposal or contract:
- Written scope or statement of work, including what is out of scope.
- List of deliverables: software, source code, documentation, design files, credentials.
- Acceptance process with review periods and criteria.
- Milestones with payments tied to accepted deliverables.
- Change request process with written approval of cost and time.
- IP clause: assignment or license, effective date, and a written copyright assignment where ownership transfers.
- Background IP and open-source components identified and licensed to you.
- Repository access for your company during the project.
- Domain, hosting, and third-party accounts in your company's name.
- Data ownership and export in a standard format.
- Confidentiality obligations for both sides.
- Warranty or bug-fix period after launch.
- Maintenance and support terms with response times, if you need them.
- Termination terms and payment for work completed.
- Handover clause with a deadline for code, data, credentials, and documentation.
- Governing law and dispute resolution.
How Does inSpace Handle Ownership and Licensing?
At inSpace we agree on ownership and licensing in writing before a project starts, so there are no surprises later about who owns the code, the data, or the accounts. We would rather spend an extra conversation on the contract at the beginning than leave a client unsure about what they paid for.
If you are planning a website, a web app, or custom software development, we are happy to walk through scope, pricing models, and ownership with you, and we encourage you to have your own attorney review whatever you sign. Book a free 30-minute call and bring your questions, or the contract you are reviewing.