Hiring a developer or development agency to build software for your business is one of the most IP-sensitive contracts your company will sign. When it goes wrong, the consequences are not limited to project delays or cost overruns. You can end up paying for code you do not own, shipping a product that infringes third-party licenses, or having a vendor walk away with your confidential technical architecture and build something competitive with it.
A software development agreement is the contract between you (the client) and the developer or agency that defines the scope of work, payment terms, ownership of the deliverables, and the legal framework for everything that can go wrong during a complex technology project. It is different from a generic services agreement because software development creates intellectual property, and the IP ownership question in a development engagement is not resolved by payment alone.
This article covers what a software development agreement must address, where clients and developers typically disagree, and how a technology lawyer structures these agreements differently from general contract counsel.
1. The IP Ownership Problem That Kills Deals Later
Under US copyright law (17 U.S.C. § 101), code written by an independent contractor belongs to the contractor by default. This is not intuitive, but it is the law. The work-made-for-hire doctrine that automatically transfers copyright to employers for employee-created work does not apply to independent contractors except for a specific closed list of categories that does not include software.
This means that a startup that hired a freelance developer to build its MVP, an enterprise that engaged an offshore agency to build a core system, and a consumer brand that paid a US development shop to build its app all face the same default rule: the developer owns the code unless a written assignment agreement was signed.
Calling the payment a “work for hire” in your invoice or your project brief does not transfer ownership. Stating in an email that “we own all the work product” does not transfer ownership. The Copyright Act (17 U.S.C. § 204(a)) requires a copyright assignment to be in a signed writing to be valid. Your software development agreement is that writing.
A software development agreement must include an explicit copyright assignment clause that transfers ownership of all code, documentation, and other deliverables created under the agreement to the client. This assignment should be effective as of the date of creation, not the date of delivery or acceptance.
2. Scope of Work: The Clause That Generates the Most Disputes
The scope of work defines what the developer is obligated to deliver. In software development, scope disputes are the primary driver of litigation and arbitration. The client thought the agreement covered one thing; the developer thought it covered another. Both parties were relying on the same contract language.
What a Scope of Work Must Include
The scope of work should identify the specific features and functionality to be delivered, the platforms and environments it must work in (web browser, iOS, Android, Windows, specific API integrations), the technical specifications that define what “done” looks like, and the deliverables that accompany the code (documentation, source code repositories, test suites, deployment scripts).
If deliverables are phased, the agreement should define what each phase includes and what criteria must be satisfied before each phase is considered complete. A vague milestone structure (“Phase 1: Development begins”) does not give either party a clear standard for when payment is due, when the client can accept or reject work, or when the developer’s obligations for a particular phase are finished.
Exclusions Are As Important As Inclusions
The scope should explicitly exclude what is not covered. If the agreement does not cover ongoing maintenance, hosting, third-party API costs, content creation, or security testing, those exclusions should be stated. Without them, the client may have a reasonable expectation that the developer will handle tasks the developer never intended to perform, and the resulting dispute is about what the contract covered, which is the most expensive kind of dispute to resolve.
Change Order Process
Software development scopes change. Requirements evolve, priorities shift, and clients discover they need something different than what they originally specified. The agreement must include a documented change order process that establishes how scope changes are requested, how they are priced, and how they affect timelines. Without this, the developer either does extra work for free because the client argues it was implied in the original scope, or the project stalls while the parties negotiate every deviation from the original plan.
3. Payment Structure and Conditions
Software development agreements typically structure payment in one of three ways: fixed-price contracts where the client pays a set amount for a defined deliverable, time-and-materials contracts where the client pays for developer hours and costs, or milestone-based contracts where payment is tied to delivery and acceptance of specific project phases.
Fixed-Price Contracts
Fixed-price contracts protect clients from cost overruns but create scope risk: the developer’s incentive is to deliver the minimum that satisfies the agreement’s language, not to build the product the client actually envisioned. Fixed-price agreements need extremely precise scope definitions to work. When scope is unclear, the developer delivers to the minimum interpretation, the client rejects the deliverable as incomplete, and the resulting dispute can exceed the contract value in legal costs.
Time-and-Materials Contracts
Time-and-materials contracts transfer cost risk to the client. The developer bills for their actual time and expenses, the client pays as work progresses, and the final cost depends on how long the project takes. These agreements work best when scope is inherently variable or when the client wants control over how developer time is allocated. They require careful oversight mechanisms to prevent cost escalation, including rate caps, maximum hour commitments, and regular reporting requirements.
Milestone-Based Payment and Acceptance
Milestone-based payment ties disbursements to the completion of defined project phases. The key legal issue is the acceptance criterion: what standard must the deliverable meet for payment to become due? The agreement should define what acceptance means (functional testing, client review period, compliance with written specifications) and what happens if the client rejects a deliverable (how many revision cycles are included, what happens after revisions, and whether rejection without cause gives rise to a payment obligation).
Without a defined acceptance process, the client’s payment obligation can become ambiguous when they are dissatisfied with the deliverable. Without a rejection standard, the developer may have no protection against a client who withholds payment without legitimate grounds.
4. Confidentiality and Pre-Existing IP
Software development engagements involve extensive disclosure of confidential technical information. The client discloses their business requirements, technical architecture, proprietary processes, and strategic roadmap. The developer may disclose their development methodologies, proprietary tools, and technical approaches. Both parties need confidentiality protections, and the development agreement should address them directly rather than relying on a separate NDA.
Client Confidential Information
The agreement should classify the client’s technical specifications, architecture documents, business logic, trade secrets, and any non-public information shared during the engagement as confidential, require the developer not to disclose or use it for any purpose other than performing the agreement, and specify that these obligations survive termination of the engagement for a defined period.
Developer Pre-Existing IP
Developers often use pre-existing tools, libraries, frameworks, and proprietary code they developed before the engagement. This pre-existing IP belongs to the developer, not the client, regardless of the IP assignment clause. Your agreement must address this by requiring the developer to disclose any pre-existing IP incorporated into the deliverables, define what license the client receives to use that pre-existing IP (typically a license to use it as embedded in the deliverable, not ownership), and confirm the client can continue to use the deliverables if the developer relationship ends.
A developer who incorporates significant proprietary tools into your product without disclosing this creates a dependency: you own the surface-level code but need the developer’s continued cooperation to maintain the embedded components. Identifying and addressing pre-existing IP in the agreement eliminates this leverage.
5. Open-Source and Third-Party Components
Modern software development involves extensive use of open-source libraries and third-party components. This is not problematic in itself, but it creates IP and licensing obligations that your software development agreement must address.
Copyleft open-source licenses (GNU GPL, LGPL, AGPL) impose conditions on software that incorporates them: in some cases, the entire product must be distributed under the same open-source license if the product is distributed to others. If your developer builds your commercial product using GPL-licensed components without flagging this, you may find that your entire codebase is subject to open-source distribution requirements when you go to sell, license, or distribute the product.
Your agreement should require the developer to maintain a list of all open-source and third-party components incorporated into the deliverables, disclose the license applicable to each component, and represent that the use of those components is compatible with the client’s intended use (commercial distribution, proprietary licensing, and so on). For technology companies building commercial products, the open-source compliance question belongs in the development agreement, not as an afterthought during product launch.
6. Warranties, Liability, and Defect Correction
Software development agreements should include a warranty period during which the developer is obligated to fix defects in the delivered code at no additional charge. The typical warranty period ranges from 30 to 90 days post-delivery. The agreement should define what constitutes a defect (code that does not conform to the written specifications), how defects are reported, and what the developer’s response time obligation is.
Beyond the warranty period, defect correction is typically billed as additional work. The agreement should specify whether ongoing support and maintenance are included, excluded, or available under a separate agreement. If maintenance is not addressed, the client may reasonably expect it to be included while the developer considers it out of scope.
The limitation of liability clause in a development agreement protects the developer from claims that exceed the contract value. A limitation capping the developer’s total liability to the amount paid under the agreement is standard. Clients sometimes resist this because it means a defect in a $50,000 development project that causes $500,000 in downstream business losses caps the developer’s liability at $50,000. That is the tradeoff: the developer cannot price unlimited liability into a fixed engagement. The client’s protection is the warranty, the indemnification clause, and the quality of the specifications they provided.
7. Indemnification and Third-Party Claims
The indemnification clause addresses who bears responsibility when the software development engagement causes a third-party claim. The two most common scenarios are IP indemnification (a third party claims the deliverables infringe their copyright, patent, or trademark) and data security incidents (the software processes personal data and a breach causes regulatory or civil liability).
The developer should indemnify the client for IP claims arising from the developer’s pre-existing IP or from code the developer created that infringes a third party’s rights. The client should represent that their business requirements and any materials they provided do not infringe third-party IP, so that infringement arising from following client specifications falls on the client, not the developer.
Technology lawyers who work with software development contracts understand how these indemnification clauses interact with the limitation of liability and where they create unintended consequences. A client who insists on uncapped IP indemnification from a developer, for example, may find the developer’s negotiated price reflects that uncapped exposure. Getting these terms balanced is a function of understanding how software development projects actually generate liability, which is a product-specific question rather than a general contract question.
Our contract attorney practice at TOSLawyer works with technology businesses on software development agreements from both sides: clients hiring developers and development companies reviewing client-provided paper. Whether you are engaging contractors to build a product or reviewing an agreement a client wants you to sign, the specific IP ownership, scope, and liability terms determine your exposure throughout the project and long after delivery.
Frequently Asked Questions
Do I own the code a developer writes for me if I pay them?
Not automatically. Under US copyright law, code written by an independent contractor belongs to the contractor by default. The work-made-for-hire exception that applies to employees does not apply to independent contractors for software development. The only way to own code written by a contractor is a written IP assignment agreement signed by the contractor before the work begins. Your software development agreement should include this assignment clause explicitly.
What is the difference between a fixed-price and time-and-materials software development agreement?
A fixed-price agreement sets a total price for defined deliverables. The client pays the agreed amount; the developer delivers to the specified scope. Cost risk sits with the developer. A time-and-materials agreement charges the client for developer hours at an agreed rate plus direct costs. Cost risk sits with the client. Neither model is categorically better; the right choice depends on how well-defined the scope is. Poorly defined scopes and fixed-price contracts create expensive disputes.
What should I do if a developer incorporated open-source code in my product without telling me?
The first step is identifying what open-source components were used and what licenses they carry. Copyleft licenses (GPL, LGPL, AGPL) can impose distribution conditions on commercial software that incorporates them, which may affect how you can sell or license your product. If the developer did not disclose this and you have a representation in your agreement that the deliverables are free of incompatible third-party licenses, you have a breach of contract claim. A technology lawyer who handles software IP can assess the specific licenses involved and what your options are.
How long should the warranty period be in a software development agreement?
The industry norm is 30 to 90 days post-delivery for defect correction. The right duration depends on the complexity of the software, the scope of acceptance testing, and how long it typically takes to discover defects in normal use. Enterprise software with complex integrations benefits from a longer warranty period. Custom software built to detailed specifications with thorough acceptance testing may need only 30 days. The agreement should define “defect” precisely so the warranty period covers real non-conformance with specifications, not general dissatisfaction with design choices.
Can a developer use the software they built for me to build something for a competitor?
They can use their skills and general knowledge; they cannot use your confidential information or, typically, the specific code they assigned to you. A well-drafted software development agreement includes a confidentiality clause protecting your technical specifications and business logic, a clear IP assignment that transfers the deliverable code to you, and a representation that the developer’s pre-existing IP (which they can continue to use) is disclosed and scoped. Whether non-compete provisions are appropriate depends on the nature of the engagement and applicable state law.
Get the Ownership and Scope Terms Right Before Development Begins
A software development project that begins without a clear agreement on IP ownership, scope, payment milestones, and defect responsibility creates disputes that cost far more to resolve than the contract was worth. The IP question alone, where a contractor retains rights to code you paid for, is a situation that can stop a fundraising round, complicate an acquisition, or give a departing developer leverage over your product roadmap.
If you are about to engage developers to build software, or if you received a development agreement from a client and want to understand what you are being asked to sign, contact Hansen Tong at TOSLawyer.com. Our contracts practice works with technology businesses on development agreements, IP assignments, and the software licensing structures that protect your product and your business.