In short
A software development agreement governs a bespoke build — scope, milestones, acceptance testing, price and, critically, who owns the resulting code. Without clear acceptance criteria and an IP assignment clause, developers and clients routinely end up arguing over whether a deliverable is finished and who's entitled to use it afterwards.
Fixed price, time and materials, or milestone-based
The pricing structure drives most of the other drafting decisions. Fixed-price builds need tightly defined scope and a rigorous change control process, because every undocumented request becomes a margin problem for the developer or an unbudgeted cost for the client. Time and materials arrangements need transparent reporting obligations and a cap or check-in mechanism so costs don't run away. Milestone-based agreements sit in between — we tie payment to defined, testable deliverables rather than vague project phases like 'development' or 'testing'.
Acceptance testing that actually resolves disputes
Most development disputes come down to one question: is it finished? We draft objective acceptance criteria against a written specification, a defined testing period during which the client must raise defects in writing, and a clear consequence if they don't — usually deemed acceptance after a set number of business days. We also separate critical defects that block acceptance from minor defects that don't, so a client can't withhold an entire milestone payment over a cosmetic bug.
Ownership of custom code versus background IP
This is the clause both sides most often get wrong. Custom code written specifically for the client is typically assigned to the client on full payment, but developers rarely start from a blank page — they bring pre-existing frameworks, libraries, internal tooling and reusable components built up over other engagements. We separate 'background IP' (owned by the developer and licensed to the client for use in the delivered software) from 'foreground IP' (the custom code, assigned to the client), and make clear that assignment of foreground IP is conditional on payment actually clearing, not just on delivery.
Where third-party or open-source components are incorporated, the agreement should require the developer to disclose them and confirm the licence terms are compatible with the client's intended use, particularly for anything with copyleft obligations that could affect the client's ability to keep its own code proprietary.
Source code escrow
Where a client is relying on a single developer or small vendor for a business-critical system, a source code escrow arrangement — depositing the current source with an independent third party, released to the client if the developer becomes insolvent or stops supporting the software — protects continuity without requiring the developer to hand over source code it isn't ready to release. We draft the escrow trigger events and update obligations to make the arrangement genuinely useful rather than symbolic.
Warranties, defect liability and post-delivery support
We include a defined defect liability period after acceptance during which the developer must fix defects at no additional cost, distinct from any ongoing support and maintenance arrangement that follows it. Warranties are limited to the software conforming to the agreed specification — open-ended warranties that the software will be 'fit for purpose' or 'error-free' create exposure no fixed-fee engagement is priced to cover.
Liability and termination
Liability caps are set by reference to fees paid, with carve-outs for IP infringement and confidentiality breaches. Termination rights address what happens to part-completed code and payment for work in progress if the project is terminated before completion, so neither side is left with an unresolved dispute over unfinished deliverables.
What the fixed fee covers
- Full software development agreement with your chosen pricing model
- Acceptance testing and defect classification schedule
- Background IP versus foreground IP ownership clause
- Source code escrow clause (or arrangement with an escrow agent) where required
- Warranty, defect liability period and support transition terms
- One round of negotiation support
Mistakes we see
- No written specification, so 'acceptance' has nothing objective to test against
- IP assigned to the client without carving out the developer's reusable background code
- Fixed-price agreement with no change control process for scope creep
- Assignment of IP triggered on delivery rather than on payment clearing
- No disclosure obligation for open-source components with copyleft licence terms
Who this is for
- Businesses commissioning bespoke software, apps or platforms
- Software development studios and freelance developers
- Startups engaging outsourced development teams
- Businesses relying on a single vendor for a business-critical system
Frequently asked questions
- Who owns the code if we haven't signed anything yet?
- Under the Copyright Act 1968 (Cth), copyright in code created by an independent contractor generally vests in the contractor, not the commissioning party, unless the agreement assigns it. A verbal understanding that 'we own it because we paid for it' isn't legally reliable — get the assignment in writing before the build starts.
- Can the developer keep using code they wrote for us on other projects?
- Only for genuine background IP — pre-existing frameworks, tools and libraries — not for the custom logic specific to your business. We draft the licence back to the developer narrowly enough that it doesn't give a competitor access to your proprietary functionality.
- Is source code escrow worth it for a smaller project?
- It adds cost and administrative overhead, so it's usually reserved for systems your business genuinely can't operate without and where you're relying on one developer or a small vendor with limited bench strength. For lower-stakes builds, a straightforward IP assignment on payment is usually sufficient.
- What happens if the client keeps changing requirements mid-build?
- That's what the change control clause is for — every material change to specification should go through a written variation request, costed and approved before work continues, so the developer isn't absorbing unpaid scope and the client isn't blindsided by cost overruns.
- Does the agreement need to cover ongoing support after launch?
- We recommend addressing it even briefly — either committing to a separate support and maintenance agreement or explicitly stating that support isn't included, so there's no ambiguity about who fixes production issues once the defect liability period ends.
Related