Software projects fail on contracts in predictable ways. The client assumes "the app" includes an admin panel nobody specified. The developer assumes acceptance happens when code is merged; the client assumes it happens when the app is in the store. Six months later both sides discover they never agreed who owns the component library the developer has used on every project since 2021.
This agreement is written for freelance developers and small studios building web apps, mobile apps, APIs and internal tools. It works as a master agreement: the legal and commercial terms live here, and the feature-level scope goes into a statement of work you attach and replace per phase.
TL;DR
The software development agreement template covers engagement model (fixed price or sprints), statement-of-work scope, acceptance testing with a deemed-acceptance window, change requests, code ownership on payment, pre-existing and open source code, credentials and hosting, security duties, and a 30-90 day defect warranty. Sign it before the first commit. Attach a statement of work for each phase rather than rewriting the agreement.
What's inside
- Engagement model — fixed-price milestones or time-and-materials sprints, chosen per statement of work.
- Scope by statement of work — feature scope, tech stack and environments live in an attached SOW.
- Acceptance testing — a test window, written defect reports, and deemed acceptance.
- Change requests — how new features are estimated, approved and billed.
- Intellectual property — client owns custom code on payment; developer keeps background code under a license.
- Open source and third-party services — disclosure and pass-through of license and API terms.
- Access, credentials and hosting — who owns accounts and repositories.
- Security and data — reasonable security practice and handling of personal data.
- Warranty and support — a defect window and what falls outside it.
When to use it
Use it for any build longer than a couple of weeks: an MVP, a custom integration, a rebuild of a legacy tool, a mobile app. Write the detailed features into the software development SOW, so phase two only needs a new SOW, not a new contract. If you're still in the sales stage, the app development proposal is where pricing and scope options belong.
For a marketing website built on a CMS, the web design contract is a better fit; it deals with content, design rounds and hosting handover rather than sprints and code ownership. For pure maintenance work, use a retainer instead.
Clauses developers regret leaving out
Background IP. Your auth boilerplate, deployment scripts and UI kit are reused across clients. If the agreement assigns "all code" to the client, you may have just sold them. Carve out pre-existing and generic code, and grant the client a perpetual license to use it inside their product.
Deemed acceptance. Give the client 5-10 business days to test each milestone against written criteria. Silence counts as acceptance. Without this clause a milestone can sit in "almost done" for weeks while the invoice waits.
Third-party dependencies. Payment gateways, map APIs, app stores and cloud hosts change their terms and prices. Make the client the account holder, responsible for those fees, and exclude outages and API changes from your warranty.
Credentials and repositories. Decide on day one whether the repo lives in the client's organization or yours. Developers who hold the only admin access invite disputes; clients who hold everything and stop paying invite worse ones. A common middle ground: repo in the client's organization, admin access for you, and code ownership transferring on payment.
Security responsibilities. You can promise reasonable security practice. You can't promise the system will never be breached. Say what you will do (dependency updates during the build, no secrets in the repo, least-privilege access) and what the client owns after handover.
Fixed price or sprints
Fixed price suits a narrow, well-specified build. Put a tight scope in the SOW, require change requests for anything new, and price in a buffer of 15-25% for the unknowns you already know about. Time and materials, billed in one- or two-week sprints, suits products where the client is still learning what they need. You estimate, they prioritize, and both of you review progress every sprint. The fixed-fee scoping article goes deeper into writing a scope you can defend.
Customize it in your COLO workspace
Keep this agreement as a contract template in COLO Contracts, with your company signature added; the client signs in the client portal with a typed name or signature image. Track the build as a project with tasks, priorities and a per-task rate, and use the timer or manual entries to log billable and non-billable hours, then create the sprint invoice straight from tracked time on COLO invoicing.
Common mistakes
- Assigning all IP with no carve-out. You lose the right to reuse your own tooling.
- Acceptance tied to launch. Launch dates depend on app store review and the client's marketing team. Tie acceptance to tested deliverables.
- Hosting on your account. You end up paying the client's cloud bill, or holding their production system hostage by accident.
- Unlimited warranty. A warranty that covers "all bugs, forever" turns into free maintenance.
FAQ
Q: Who owns the source code in a software development agreement?
Whoever the agreement says. A common arrangement is that the client owns the custom code written for the project once paid in full, while the developer keeps ownership of pre-existing libraries and tools and grants the client a license to use them inside the product.
Q: Should I use fixed price or time and materials for software?
Fixed price works when the scope is well specified and stable. Time and materials, usually billed in sprints, suits products where requirements will change. Many developers run a fixed-price discovery phase first, then bill the build on time and materials.
Q: How long should a bug-fix warranty last?
Thirty to ninety days after acceptance is common. Limit it to defects where the software does not match the agreed specification, and exclude problems caused by client changes, third-party services or hosting.
Q: What is an acceptance testing clause?
It gives the client a fixed number of days to test each delivery against agreed criteria and report defects in writing. If they report nothing in that window, the delivery is treated as accepted, which keeps the project and payments moving.
Q: Do I need to list open source components?
It is good practice to disclose open source dependencies and their licenses, especially copyleft licenses that may affect how the client can distribute the software. The agreement should say the client accepts those license terms.