A software development contract covers specifications and scope (fixed-scope or time-and-materials/agile), milestone payments with acceptance criteria, acceptance testing procedure (test window, defect severity classes, deemed acceptance), IP assignment on payment with carve-outs for developer tools and open-source components, source code and repository delivery, warranties (30–90 day defect warranty), support/maintenance terms, and liability caps. Rates run $75–$250/hour; agile engagements bill per sprint with the client owning the backlog.
Software Development Agreement Template
Reviewed by the Agiled editorial teamUpdated June 2026
Software contracts fail where software does: at the gap between what was specified and what was meant. The contract's machinery for that gap is acceptance —...
Part of our free contract template library — 75+ agreements in Word and PDF, ready to customize and sign.
Full template text
SOFTWARE DEVELOPMENT AGREEMENT
This Software Development Agreement ("Agreement") is entered into as of [Effective Date] by and between:
Client: [Client Legal Name], a [State/Entity Type] with its principal place of business at [Address] ("Client")
Developer: [Developer Legal Name], a [State/Entity Type] with its principal place of business at [Address] ("Developer")
Collectively referred to as the "Parties."
RECITALS
WHEREAS, the Client desires to engage the Developer to design, develop, test, and deliver custom software; and
WHEREAS, the Developer possesses the technical expertise and resources to perform such services;
NOW, THEREFORE, the Parties agree as follows:
1. PROJECT SCOPE
1.1 The Developer shall design, develop, test, and deliver the software product described in the Project Specifications attached as Exhibit A ("Software").
1.2 The Project Specifications shall include: functional requirements, technical architecture, platform and technology stack, user interface wireframes or mockups, performance requirements, and integration specifications.
1.3 Any work not explicitly described in the Project Specifications is outside the scope of this Agreement and shall be subject to a Change Order pursuant to Section 7.
2. DEVELOPMENT MILESTONES
2.1 The Project shall be divided into the following milestones, each with defined deliverables and target completion dates as detailed in the Milestone Schedule (Exhibit B):
(a) Milestone 1: Requirements Validation and Architecture Design;
(b) Milestone 2: User Interface Design and Prototyping;
(c) Milestone 3: Core Development (Phase 1);
(d) Milestone 4: Core Development (Phase 2);
(e) Milestone 5: Integration and System Testing;
(f) Milestone 6: User Acceptance Testing and Deployment;
(g) Milestone 7: Post-Launch Support Period.
2.2 Target dates are estimates. The Developer shall notify the Client promptly if a milestone is at risk of delay and shall propose a revised timeline.
3. ACCEPTANCE AND TESTING
3.1 Upon completion of each milestone, the Developer shall deliver the associated deliverables and notify the Client in writing.
3.2 The Client shall have [10] business days to review and test each milestone delivery ("Acceptance Period").
3.3 If the deliverables conform to the acceptance criteria defined in Exhibit B, the Client shall provide written acceptance. If the Client does not respond within the Acceptance Period, the milestone shall be deemed accepted.
3.4 If the deliverables do not conform to the acceptance criteria, the Client shall provide a written list of specific deficiencies. The Developer shall correct the deficiencies within [10] business days and resubmit. The Client shall have an additional [5] business days to re-test.
3.5 If, after two rounds of corrections, the deliverables still do not conform, the Parties shall meet to discuss resolution, which may include scope adjustments, timeline extensions, or partial acceptance.
4. COMPENSATION
4.1 The total fee for the Project is $[Total Amount] ("Project Fee"), structured as follows:
(a) Deposit upon execution: $[Amount] ([percentage]% of the Project Fee);
(b) Milestone 1 acceptance: $[Amount];
(c) Milestone 2 acceptance: $[Amount];
(d) Milestone 3 acceptance: $[Amount];
(e) Milestone 4 acceptance: $[Amount];
(f) Milestone 5 acceptance: $[Amount];
(g) Milestone 6 (Final Delivery) acceptance: $[Amount].
4.2 Additional work authorized through Change Orders shall be billed at $[Rate] per hour or as specified in the applicable Change Order.
5. PAYMENT TERMS
5.1 The Developer shall submit invoices upon achievement and acceptance of each milestone.
5.2 The Client shall remit payment within [15] business days of receiving a valid invoice.
5.3 Late payments shall accrue interest at [1.5]% per month.
5.4 If payment is more than [30] days overdue, the Developer may suspend work upon [5] business days' written notice. Work shall resume within [3] business days of receipt of all outstanding payments.
6. INTELLECTUAL PROPERTY
6.1 Upon full payment for each milestone, all intellectual property rights in the custom code, designs, and documentation created by the Developer for that milestone ("Work Product") shall be irrevocably assigned to the Client.
6.2 The Developer retains ownership of all pre-existing intellectual property, tools, libraries, and frameworks ("Developer IP") used in the Project. The Developer grants the Client a perpetual, worldwide, royalty-free, non-exclusive license to use Developer IP as incorporated in the Work Product.
6.3 Third-party components, including open-source software, shall be identified in a dependency manifest (Exhibit C). The Client acknowledges that such components are governed by their respective licenses.
6.4 Until full payment is received for a milestone, the Developer retains ownership of the associated Work Product.
7. CHANGE ORDERS
7.1 Either Party may propose changes to the Project Specifications by submitting a written Change Request describing the proposed change.
7.2 The Developer shall evaluate the Change Request and provide a written Change Order specifying the impact on scope, timeline, and cost within [5] business days.
7.3 A Change Order becomes effective only upon written approval by both Parties.
7.4 The Developer shall not perform work on proposed changes until the corresponding Change Order is approved.
8. CONFIDENTIALITY
8.1 Each Party shall maintain the confidentiality of the other Party's proprietary information, including business plans, technical specifications, source code, user data, pricing, and financial information ("Confidential Information").
8.2 Confidential Information shall not be disclosed to third parties without prior written consent, except to employees and contractors who need access for the Project and are bound by confidentiality obligations.
8.3 This obligation survives termination for [3] years.
9. WARRANTIES
9.1 The Developer warrants that the Software shall conform to the Project Specifications and function substantially as described therein for a period of [90] days following final acceptance ("Warranty Period").
9.2 During the Warranty Period, the Developer shall correct any material defects or non-conformities at no additional charge within a commercially reasonable timeframe.
9.3 This warranty does not cover defects arising from the Client's modifications to the Software, use of the Software in a manner inconsistent with its documentation, or third-party interference.
9.4 EXCEPT AS EXPRESSLY SET FORTH IN THIS SECTION, THE DEVELOPER DISCLAIMS ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
10. LIMITATION OF LIABILITY
10.1 Neither Party shall be liable for indirect, incidental, consequential, special, or punitive damages, including lost profits, lost data, or business interruption.
10.2 Each Party's total aggregate liability under this Agreement shall not exceed the total Project Fee.
11. INDEMNIFICATION
11.1 The Developer shall indemnify and hold harmless the Client from third-party claims alleging that the Work Product infringes any intellectual property right, provided the Client promptly notifies the Developer and cooperates in the defense.
11.2 The Client shall indemnify and hold harmless the Developer from third-party claims arising from the Client's use of the Software, content provided by the Client for incorporation into the Software, or the Client's breach of this Agreement.
12. SOURCE CODE AND DOCUMENTATION
12.1 The Developer shall deliver complete, well-documented source code for all Work Product upon final acceptance and payment.
12.2 The Developer shall provide technical documentation including architecture overview, API documentation, database schema, deployment instructions, and configuration guides.
12.3 The Developer shall provide user documentation sufficient for the Client's intended users to operate the Software.
13. TERMINATION
13.1 Either Party may terminate this Agreement for convenience by providing [30] days' written notice.
13.2 Either Party may terminate immediately if the other Party materially breaches this Agreement and fails to cure within [15] days of written notice.
13.3 Upon termination: (a) the Client shall pay for all accepted milestones and any work completed but not yet accepted, calculated on a pro-rata basis; (b) the Developer shall deliver all Work Product completed to date, including source code and documentation; (c) confidentiality, IP assignment (for paid work), and limitation of liability provisions shall survive.
14. INDEPENDENT CONTRACTOR
14.1 The Developer is an independent contractor. Nothing in this Agreement creates an employment, agency, partnership, or joint venture relationship.
15. GOVERNING LAW AND DISPUTE RESOLUTION
15.1 This Agreement shall be governed by the laws of the State of [State].
15.2 Disputes shall first be submitted to good-faith negotiation between senior representatives of both Parties. If unresolved within [15] days, disputes shall be submitted to mediation. If mediation fails within [30] days, disputes shall be resolved by binding arbitration in [City, State].
16. GENERAL PROVISIONS
16.1 This Agreement, together with its Exhibits, constitutes the entire agreement between the Parties.
16.2 Amendments and Change Orders require written approval by both Parties.
16.3 If any provision is found unenforceable, the remaining provisions continue in full force.
16.4 Neither Party may assign this Agreement without prior written consent.
16.5 Notices shall be in writing and sent to the addresses listed above.
IN WITNESS WHEREOF, the Parties execute this Agreement as of the Effective Date.
CLIENT:
Signature: ___________________________
Name: [Authorized Representative]
Title: [Title]
Date: ___________________________
DEVELOPER:
Signature: ___________________________
Name: [Authorized Representative]
Title: [Title]
Date: ___________________________
- Rates
- $75 – $250 / hour
- Model
- Fixed-scope or T&M/agile
- Defect warranty
- 30 – 90 days
- IP assignment
- On payment, tools carved out
What your software development contract should cover
Scope and specifications
Fixed-scope: the spec is a contract document — features, user stories, and out-of-scope items listed. T&M/agile: the contract governs process (sprint length, rates, roles) while the backlog governs content, with the client owning prioritization. Mixing the models without saying so is how both sides lose.
Milestones and payment
Fixed-scope: payments tied to milestone acceptance (30–40% mobilization, then per-milestone). T&M: sprint or monthly invoicing, net-15/30, with burn-rate reporting against the estimate. Deposits before sprint one in either model.
Acceptance testing
Per milestone: a test window (5–15 business days), defects classed by severity (critical/major/minor), acceptance with minor defects scheduled for fixes versus rejection only for critical/major, and deemed acceptance if the window passes silently. Production use is acceptance — deploying it and rejecting it are mutually exclusive.
Change control
Fixed-scope: changes priced (cost and schedule) and signed before work. Agile: change is the process — but scope additions extend sprints rather than compressing quality, and the contract should say the velocity math out loud.
IP assignment and carve-outs
Deliverable code assigns to the client on full payment. Carved out and licensed: the developer's pre-existing libraries, tools, and generic know-how. Without the carve-out, the developer assigns away their toolkit; without the assignment, the client rents their own product.
Open-source disclosure
OSS components listed with licenses; copyleft (GPL/AGPL) flagged before integration — an AGPL dependency in a proprietary SaaS product is a business-model decision, not a technical one. Client approval required for copyleft.
Delivery: code, repo, and environment
Source delivered via repository transfer (the client owns or gains the repo), build and deployment documentation, environment configs and secrets handed over, and third-party accounts (cloud, CI, registries) in the client's name from day one.
Warranty and support
30–90 days: delivered code performs per spec, defects fixed free. After: a support/maintenance agreement (monthly retainer or hourly) — bug fixes, dependency updates, and security patches are ongoing costs, not warranty tails.
Confidentiality and data
Mutual NDA terms, client data handled per stated security practices, production-data access minimized and logged, and breach-notification commitments where the developer touches regulated data (HIPAA/PCI work needs its own addenda).
Liability, indemnity, and non-solicitation
Liability capped at fees (or 12 months of fees on ongoing engagements), no consequential damages, IP-infringement indemnity from the developer for delivered original code, and mutual non-solicitation of staff for 12 months.
Typical software development terms (U.S., 2026)
| Item | Typical range | Notes |
|---|---|---|
| Hourly rates | $75 – $250 | Stack, seniority, onshore/offshore |
| MVP build | $25,000 – $150,000+ | Scope-driven |
| Deposit / mobilization | 30 – 40% | Fixed-scope projects |
| Acceptance window | 5 – 15 business days | Deemed acceptance after |
| Defect warranty | 30 – 90 days | Per-spec performance |
| Maintenance retainer | 10 – 20% of build/yr | Industry rule of thumb |
| Liability cap | Fees paid | Or 12 months on retainers |
Rates vary by stack, seniority, and geography. The acceptance and IP clauses matter more than the rate — they decide who owns the product and when payment is owed.
How software development contracts work in practice
The fixed-scope MVP
A defined product for a defined price: the model works when the spec is real. The contract earns its keep at three points — the spec as contract document (wireframes and user stories attached, ambiguity resolved in writing before pricing), milestone acceptance with the deemed-acceptance clock (a client who won't test can't withhold forever), and change control (the 'small addition' to the spec is priced, because fixed-scope margins die from a hundred small additions). Developers should pad estimation risk into the price honestly; clients should expect to pay for certainty.
The agile T&M engagement
Sprints, a backlog the client owns, and invoices that track hours: flexibility priced at the client's risk. The contract governs the process — sprint length, team composition and rates, demo and invoice cadence, the client's product-owner obligations (backlog groomed, questions answered within a stated SLA, because an unresponsive product owner burns budget on guesses) — plus the estimate-versus-commitment honesty: the roadmap is a forecast, the sprint is the commitment. The protection both sides need: either can exit at a sprint boundary with notice, code and IP current through the last paid sprint.
The handover and the bus factor
The engagement ends — amicably or not — and the client needs to own their product in practice, not just on paper. The contract's handover list: repository ownership transferred (not a zip file — the history matters), CI/CD and infrastructure accounts in the client's name, environment variables and secrets rotated and delivered, build-from-scratch documentation verified by an actual clean build, and a paid transition window for the next team's questions (10–20 hours typical). The clients who skip the documented-handover clause discover the real meaning of vendor lock-in: not malice, just entropy nobody was paid to prevent.
Mistakes that weaken a software development contract
No acceptance procedure
Without a test window and severity classes, 'it's not what we wanted' can stall final payment indefinitely — and 'it works on my machine' can dodge real defects. The acceptance clause protects both directions.
IP assignment without the tools carve-out
A blanket assignment hands the client the developer's accumulated libraries and snippets. Carve out pre-existing IP, license it perpetually for the deliverable, and assign only the project's new code.
Silent open-source integration
An undisclosed AGPL dependency in proprietary SaaS is a license violation with the client's name on it. Disclose the OSS bill of materials; get sign-off on anything copyleft.
Warranty as free maintenance
A defect warranty covers 'doesn't perform per spec' for 30–90 days — not new features, environment changes, or the dependency treadmill. Price maintenance as the ongoing service it is (10–20% of build cost annually is the rule of thumb).
Client accounts in the developer's name
Cloud, domains, and app-store accounts registered to the developer create hostage dynamics at every rough patch. Client-owned accounts with developer access — from day one, both sides sleep better.
How to use this template
- 01
Download the software development contract template in Word or PDF.
- 02
Choose the model — fixed-scope with spec attached, or T&M with sprint process terms.
- 03
Set milestones, payment schedule, and the acceptance procedure with deemed acceptance.
- 04
Write the IP assignment with tools carve-out and the open-source disclosure rule.
- 05
Define delivery: repo transfer, docs, accounts in client's name, transition hours.
- 06
Set the defect warranty, liability cap, and non-solicitation, then sign before sprint one.
Skip this template if…
- Hiring a developer as ongoing staff — set hours and full integration into your team is employment or staff augmentation, with different terms.
- Website design-and-build projects — a web design contract covers content, browser targets, and launch without acceptance-testing machinery.
FAQs
How much does custom software development cost?
Rates run $75–$250/hour depending on stack, seniority, and geography; MVP-scale products typically land $25,000–$150,000+, with complex platforms well beyond. Plan for maintenance at 10–20% of build cost annually — dependencies, security patches, and platform changes don't pause when the project ends.
Fixed-price or time-and-materials — which is better?
Fixed-price buys certainty when the spec is genuinely stable — the developer owns estimation risk and prices it in, and every change becomes a negotiation. T&M/agile fits evolving products — the client owns the backlog and the risk, paying for flexibility. The honest test: if the spec would survive three months unchanged, fix the price; if not, don't pretend.
What is acceptance testing in a development contract?
The defined procedure for approving deliverables: a test window (5–15 business days), defects classed by severity, rejection reserved for critical/major issues (minor ones get scheduled fixes), and deemed acceptance if the window passes without feedback. The companion rule: deploying to production is acceptance — a client can't run the code and reject it simultaneously.
Who owns the code in custom software development?
The standard structure: new code written for the project assigns to the client on full payment, while the developer's pre-existing libraries and tools stay theirs, licensed perpetually for use in the deliverable. Open-source components keep their own licenses regardless — which is why the OSS disclosure list belongs in the contract.
What warranty applies to delivered software?
Typically 30–90 days: the code performs per the specification, and defects are fixed free. It doesn't cover new features, third-party API changes, or dependency updates — that's maintenance, properly sold as a retainer. Liability caps at fees paid are standard, with the developer indemnifying for IP infringement in original delivered code.
What should a software handover include?
Repository transfer with full history, build and deployment documentation verified by a clean build, environment configs with secrets rotated, all third-party accounts (cloud, CI, registries) in the client's name, the OSS license inventory, and a paid transition window (10–20 hours) for the next team's questions. Handover quality is decided when the contract is signed, not when the engagement ends.
Pair it with the software development invoice template
The contract sets the terms — the invoice collects on them. Free download with the right line items pre-filled.
Need more than a template?
Create, send, and e-sign contracts with Agiled — alongside your CRM, invoicing, and projects.
Start free with Agiled