You are about to sign — or send — a software development agreement. Maybe a developer has handed you their standard form. Maybe you are the developer and you built your template from a generic services contract years ago. Either way, the document in front of you will govern what gets built, when payment is due, who owns the finished code, and who absorbs the cost when things go sideways. The standard form is almost never neutral. Understanding the key clauses before you sign is the difference between a project that runs to plan and one that ends in a dispute over deliverables neither party can agree were ever in scope.
A software development agreement (sometimes called a development services agreement or an IT development agreement) is a commercial contract between a client and a developer for the creation of bespoke software — a web application, a mobile app, an internal tool, a data platform, or any other custom-built system. It is not a software licence (which governs use of existing software) and it is not a maintenance agreement (which governs ongoing support after delivery). It sits upstream of both: it governs the act of building, and it should specify what happens once the build is done.
The essential clauses
What the developer will actually build
The scope of works clause is the foundation of everything else. If it is vague, every other clause in the contract becomes a coin flip. A well-drafted scope clause should:
- describe the deliverables in specific, measurable terms — platforms, features, integrations, technical environment, and any third-party services the build will rely on
- attach a written specification document as a schedule and make that schedule part of the contract
- explicitly state what is out of scope — operating systems you are not targeting, languages you are not localising for, post-launch maintenance, future feature releases
The trap: clients assume that because something was discussed before signing, it is captured in the contract. Developers assume that anything not in the specification is a variation. Both assumptions are correct — and that is exactly why the specification must be written down and agreed before a line of code is written.
How changes to scope are handled
In bespoke software development, scope changes are normal. The client's vision shifts, new requirements emerge, and what seemed clear in week one rarely looks the same in week eight. A change control clause manages this reality without leaving either party exposed.
A properly structured change control mechanism should:
- define what triggers a "change" (additions to functionality, modifications to agreed features, changes to the technical environment)
- set out the process — typically a written change request, a developer assessment, a written quote, and written approval before work begins
- specify how changes affect the timeline and the price
The drafting choice that matters most is how minor and major changes are distinguished. "Minor" changes are the ones developers absorb and clients expect to be free. If the contract does not define the boundary, every disagreement becomes a negotiation. Some contracts define minor changes by reference to time (changes requiring less than a nominated number of hours); others define them by reference to type. Either approach works — the important thing is that it is written down.
Pricing for approved changes is typically handled on an hourly rate basis. Where that rate applies and how it is invoiced should be stated explicitly, not left to be agreed at the time.
IP ownership — the clause most clients get wrong
This is the clause that generates the most disputes and the most misunderstanding in software development contracts.
Under s 35 of the Copyright Act 1968 (Cth), the author of a literary work — which includes software code — is the owner of copyright in that work. The key word is "author." In a commissioned development project, the author is the developer, not the client. There is no automatic transfer of ownership simply because the client is paying for the work.
This is not a technicality. If the development agreement is silent on IP ownership, or if it uses vague language like "the client will own all deliverables," there is a real risk that the developer retains rights in parts of the code. The only way to shift ownership is through an explicit written assignment — either in the development agreement itself or in a separate IP assignment deed executed at completion.
The typical IP structure in a development agreement distinguishes between:
- Foreground IP — the new code, interfaces, and functionality created specifically for this project. The client should expect to receive an assignment of foreground IP on payment.
- Background IP — the developer's pre-existing code, frameworks, libraries, and tools that the developer brings to the project and incorporates into the deliverables. Background IP stays with the developer and is licensed (not assigned) to the client for the purpose of using the deliverables.
The trap for developers: if the contract assigns "all IP in the deliverables" without carving out background IP, the developer may inadvertently assign ownership of code they use across dozens of client engagements. If they then reuse that code, they are potentially infringing the first client's rights.
The trap for clients: a licence to use the background IP is only as good as the terms that govern it. Check whether the licence is perpetual, whether it survives termination, and whether it covers modification of the deliverables.
The s 35 default can be varied by agreement — that is the point. But it needs to be varied explicitly, in writing, before the dispute arises.
Testing and acceptance
A testing and acceptance clause defines when the developer has performed their obligations. Without it, "completion" is a moving target — the client can keep raising defects indefinitely, and the developer has no clear right to final payment.
A well-structured acceptance mechanism works like this:
- The developer delivers the software against the agreed specification.
- The client has a defined period to review and test the deliverables.
- If defects are found, the client must notify the developer in writing within that period, specifying each defect.
- The developer has an opportunity to remedy notified defects.
- If no valid defects are raised within the acceptance period, the software is deemed accepted.
The acceptance period should be long enough to give the client a genuine opportunity to test, but not so open-ended that it becomes an indefinite hold on final payment. The specific period is a commercial negotiation — what matters is that the period is fixed, the defect notification process is written, and the deemed acceptance mechanism is clear.
The clause should also distinguish between defects that prevent use (critical) and defects that do not (minor). A client should not be entitled to withhold final payment because of a cosmetic issue if the system is otherwise functional and meets the specification.
Payment structure and milestones
Development projects are rarely paid in a single lump sum. A milestone-based payment structure ties payment to delivery of defined outputs rather than to the passage of time. Each milestone should have:
- a clear description of what must be delivered
- a due date
- the payment amount triggered by delivery
The developer's interest is in ensuring milestone payments are not contingent on acceptance of later deliverables. The client's interest is in ensuring they have leverage if early deliverables are defective. These interests can usually be reconciled by tying milestone payments to delivery and acceptance of that milestone, rather than to final acceptance of the whole project.
Suspending work for non-payment should also be addressed. If a client fails to pay a milestone, the developer should have a clear contractual right to suspend further work (with notice) rather than being in breach for doing so.
Confidentiality
Both parties will share confidential information during a development project. The developer will receive business logic, customer data structures, and technical specifications. The client will receive access to development environments, code repositories, and potentially background IP. A mutual confidentiality clause protects both.
Watch for:
- whether confidential information is defined broadly enough to capture what is actually being shared
- whether the obligation survives termination, and for how long
- carve-outs for information that becomes public through no breach of the party receiving it
Liability
Development agreements routinely include a limitation of liability clause — typically a cap on the developer's total liability set at the fees paid under the agreement, or at the fees paid in a preceding period. These clauses are standard commercial practice and courts generally uphold them between commercial parties.
Two points to check:
- Uncapped heads of loss: confidentiality breaches, IP infringement, and fraud are often excluded from any cap. This is reasonable. If the developer misappropriates your IP or leaks your customer data, a contractual cap should not shield that conduct.
- Unfair contract terms: if one party to the agreement is a small business, the unfair contract terms regime under the Competition and Consumer Act 2010 (Cth) may apply. A term that creates a significant imbalance in the parties' rights and is not reasonably necessary to protect a legitimate interest may be unenforceable.
Situational clauses worth considering
Not every development agreement needs the following, but each has a specific trigger that makes it worth raising:
- Source code escrow: if the client is operationally dependent on the software and the developer is a small firm, an escrow arrangement allows the client to access source code if the developer becomes insolvent or ceases to operate. Relevant where the client has no internal development capability to maintain the software.
- Moral rights consent: the developer (as author) has moral rights under the Copyright Act 1968 (Cth), including the right to be identified as author and the right not to have the work falsely attributed. A consent to modification and non-attribution is standard in commercial development agreements.
- Third-party software and open source: where the deliverables incorporate open-source components, the agreement should address the licence obligations that flow from that use — some open-source licences require derivative works to be released under the same terms.
- Data handling: if the development process involves access to personal information (test data sets, production data, or user information), the agreement should address how that data is handled, stored, and deleted in compliance with the Privacy Act 1988 (Cth).
- Post-completion support: a development agreement ends at acceptance. If the client wants ongoing support, bug fixes, or enhancements, that should be documented in a separate maintenance and support agreement with its own scope and pricing.
How Artificer Legal can help
The clauses in a development agreement are individually intelligible. The difficulty is in how they interact — and in the choices made during drafting that are not visible until a dispute arises.
When Artificer Legal reviews or drafts a development agreement, our focus is on the clauses that make the most difference in practice: the IP assignment and background IP carve-out (which require precise language, not just "the client owns everything"), the acceptance mechanism (which must be specific enough to trigger deemed acceptance without cutting the client off from genuine remedies), and the change control procedure (which needs to be practical enough that parties actually use it rather than agreeing to changes verbally and fighting about them later).
On the developer side, we insist on a clear background IP carve-out and a licence-back rather than an outright assignment of pre-existing tools and frameworks. On the client side, we push for explicit assignment of all foreground IP, a perpetual licence to background IP that survives termination, and a liability cap that excludes IP infringement and data mishandling from its scope.
We also flag situations where the unfair contract terms regime may affect the enforceability of standard-form clauses — particularly where a developer is using a template drafted without the small business protections in mind.
The scope of works and written specification
If there is one clause in a development agreement that determines who wins when a project goes wrong, it is the scope of works — specifically, whether the specification is written down in sufficient detail and attached to the contract. Almost every development dispute traces back to a disagreement about what was actually agreed: the client says feature X was always in scope; the developer says it was never discussed. A vague or missing specification means that argument is resolved on credibility, not on contract.
The IP ownership clause is a close second — not because it causes the most disputes (most projects finish and payment is made without the parties ever reading the assignment clause), but because when it does go wrong, the consequences are severe. A developer who has inadvertently assigned their background IP cannot use it for their next client. A client who received only a licence (when they thought they received an assignment) cannot sell the software or modify it without going back to the developer.
A development agreement is not a formality that sits in a drawer until something breaks. It is the operating manual for the project. The time to read it is before you sign, with a clear understanding of what each clause is doing and why.