Website development agreements and the clauses that decide who owns your site

A website development agreement usually arrives the way contracts do: attached to an email from the developer that says it is "just a formality" before the build kicks off. It runs to twenty pages of defined terms, and buried somewhere in the middle is the clause that decides whether you actually own the website you are about to pay for. The document deserves more than a skim, because most of the cost of getting it wrong shows up later, not at signing.

A website development agreement (sometimes called a software development agreement) sets out who builds what, for how much, and who owns the result. It replaces the email thread, the verbal brief and the quote you have been working to: once it is signed, the agreement is the deal, and anything in the earlier discussions that is not in the contract generally has no force. Reviewing it properly before you sign is part of the build, not an afterthought.

Who owns the website when the build is finished

The IP assignment clause

The clause that matters most in this document is usually the shortest. Under s 35 of the Copyright Act 1968 (Cth), the author of a work owns the copyright in it. For a website, the authors are the developer who wrote the code and the designer who produced the layouts, and source code is protected as a literary work. A freelancer or agency is an independent contractor, not an employee, so the exception that gives copyright to employers for work made under a contract of service does not help you either. By default, the developer owns the copyright in everything they create for you until it is assigned in writing.

The statute is strict about how that assignment happens. Section 196(3) requires an assignment of copyright to be in writing and signed by or on behalf of the owner, so a sentence in an email saying "you own everything" will not do the job. There is one narrow default in your favour. Under s 35(5), a photograph commissioned for a private or domestic purpose, a portrait and an engraving belong to the person who commissioned them. But a photograph taken for your business website is not for a private or domestic purpose, so even the photos stay with their creator unless the agreement says otherwise.

What the clause needs to do:

• Assign all project IP: code, designs, copy, branding and documentation, including work created after signing and work done by subcontractors.
• Carve out pre-existing tools: the developer's own libraries and frameworks stay theirs, but you get a broad, perpetual, royalty-free licence to use them as part of your site.
• Deal with third-party components: themes, plugins, fonts and stock assets, who pays for the licences and who owns them.
• Include moral rights consents: designers have rights to be attributed and to object to changes, so the agreement should record written consents that let you modify the design later.

Traps to watch for:

• Licence-only language: if the clause grants a licence instead of assigning ownership, the developer keeps the copyright and can reuse or resell your design.
• A carve-out that swallows the assignment: some agreements exclude "the developer's pre-existing materials" so broadly that most of the build ends up excluded. The carve-out should name the tools, not the deliverables.
• Subcontractor gaps: an agency's assignment only covers the agency. If subcontractors keep copyright in what they wrote, the assignment needs to flow down to them.
• No signature: check who signs the assignment. If it is a director signing for a company, the company is the assignor.

What happens when the brief changes

Scope is where projects go off the rails, so the agreement should define the work in a statement of work and set out what happens when the brief changes. A change control clause requires variations to be recorded in writing, with the price and timeline adjusted at the same time. Without one, "can you just also add" conversations accumulate and surface as a large invoice at the end. The drafting choice that matters most is whether the clause says unsigned variations have no effect. If it does, verbal instructions should not bind you, and the developer should stop work rather than build unapproved features.

Also worth pinning down at this point:

• Acceptance criteria: how each deliverable is tested, the device and browser list, and what counts as "done".
• Out of scope: what the developer is not doing, such as content writing, SEO or ongoing support, so there is a baseline for later variations.
• Milestones: a small number of checkpoints with named deliverables, rather than one giant handover.

How the price is calculated and when instalments fall due

Most developers ask for a deposit, progress payments and a final payment at handover. Linking each tranche to an accepted milestone, rather than to calendar dates, keeps quality and cash flow aligned. A holdback of five to ten per cent until defects found in the warranty period are fixed gives you leverage after launch. The agreement should also say what happens if the project is paused or cancelled: what you pay for work done to date, and whether you keep the partial work and code produced so far. If the IP clause assigns on creation, the partial work is already yours. If it assigns only on payment, cancellation gets complicated.

What the developer promises about the quality of the work

The warranties section is where the developer promises that the work is original, does not knowingly infringe anyone's IP, and meets the agreed specification with reasonable skill and care. This matters more than it looks, because the Australian Consumer Law (ACL), which is Schedule 2 of the Competition and Consumer Act 2010 (Cth), protects you less than you might expect. Under s 3 of the ACL, you acquire services as a consumer only if they cost $100,000 or less, or are of a kind ordinarily acquired for personal, domestic or household use. A small build under $100,000 can attract the consumer guarantees for services, including due care and skill and fitness for purpose, even though you are a business. But the larger the build, the more likely it falls outside the threshold, and because a business website is not a service ordinarily acquired for personal, domestic or household use, a build above $100,000 gets no statutory guarantees at all. The express warranties in the contract are your protection either way, and a business-to-business agreement that skips them leaves you with very little.

There is a second reason to read this section carefully. The unfair contract terms regime in s 23 of the ACL applies to standard form contracts with small businesses, defined as businesses with fewer than 100 employees or turnover under $10 million. An unfair term in a standard form developer agreement is void, and proposing one can attract penalties. A clause that excludes all liability for defective work, or lets the developer terminate for convenience while you cannot, is exactly the shape that draws scrutiny.

Warranties worth asking for:

• The work is original and does not infringe third-party IP.
• The site conforms to the agreed specification and is free from material defects for a defined period.
• The developer holds any licences needed for the components they supplied.
• The developer will cooperate with handover, including providing source code, admin access and documentation.

How you test and accept the site

Acceptance testing is the mechanism that turns "done" into a legal event. The agreement should describe how you test each deliverable, how long you have to report defects, and what happens then: a fix window, followed by re-testing. Payments tied to acceptance create a strong incentive to fix problems before the final invoice. The trap is signing off early, before the acceptance period has run. Once you accept the site, it is much harder to argue that it does not meet the specification. If the developer also hosts the site, the acceptance section should cover performance and uptime expectations at launch.

What the developer is liable for if things go wrong

Limitation of liability is where the push and pull happens. The developer will want a cap on total liability, usually the amount of fees paid, plus an exclusion of indirect and consequential loss. Some cap is commercially reasonable, but the carve-outs matter:

• IP indemnity: the developer should indemnify you if the site or its components infringe someone else's IP, and this should sit outside the cap.
• Confidentiality and data: liability for misuse of your confidential information or a data breach should not be capped at the fees paid, because the loss can dwarf the project price.
• Gross negligence and wilful misconduct: often excluded from the cap, which is a reasonable middle ground.

The variant the other side pushes for is a cap that applies to everything, including their own IP infringement and misuse of your data. That is the one to push back on.

How you can end the agreement and get your files back

Termination clauses are the off-ramp, and they should be practical. You want the right to terminate for the developer's breach, with a chance to cure, and ideally the right to terminate for convenience with reasonable notice, paying only for work accepted to date. The handover obligations should kick in on any termination: the latest source code, design files, admin logins, documentation and any assets held in third-party accounts, transferred within a defined period. The clause should also say which parts survive termination, typically the IP assignment, confidentiality, limitation of liability and dispute resolution provisions. A developer who holds your logins and source code hostage is a risk the clause is designed to remove.

What happens after launch

If the developer will support the site after launch, set that out separately, either in the same agreement or in a support schedule. Covered hours, response and resolution times, patching and updates, backups and the monthly fee should all be explicit, along with what is out of scope, usually new features. Without this, "we will look after it" means whatever the developer decides it means once the launch invoice is paid.

How your confidential information and customer data are protected

A confidentiality clause protects the business plans, pricing and pre-release branding you share during the project, and it should survive the end of the agreement. The data side depends on whether the Privacy Act 1988 (Cth) applies to you. If your business has an annual turnover above $3 million, or falls into one of the exceptions in s 6D of the Act, such as health service providers, businesses that trade in personal information or contracted service providers to the Commonwealth, the Australian Privacy Principles apply to how you handle personal information, and the agreement should require the developer to handle customer data consistently with those obligations.

If the developer is overseas, an additional obligation can kick in. Under Australian Privacy Principle 8, an APP entity must take reasonable steps to ensure an overseas recipient does not breach the Australian Privacy Principles, and under s 16C of the Act the recipient's handling of the information is treated as your own. Passing customer data to an offshore developer without the contractual protections in place can make your business accountable for their mistakes. If the Privacy Act does not apply to you, the confidentiality clause still matters for your commercial information, and your customers and payment providers may still expect privacy commitments in the contract.

Which country's law applies

Governing law and jurisdiction clauses decide where a dispute is heard and under which law. For an Australian developer, Australian law and jurisdiction is usually uncontroversial. For an overseas developer, the clause matters more: an Australian judgment against a developer with no assets or presence in Australia can be hard to enforce. The agreement should also include staged dispute resolution, such as negotiation, then mediation, then courts or arbitration, and robust handover rights at each milestone to reduce your dependence on the developer. Practical protections, like keeping hosting, domain and analytics accounts in your own name, do more than most clauses to reduce cross-border risk.

Clauses worth adding when the situation calls for it

Most agreements cover the core deal, but a handful of additional clauses are worth adding when the situation calls for them:

• Non-disclosure agreement: if you will share detailed plans, pricing or pre-release branding before you have chosen a developer, a short NDA before scoping protects you while you are still shopping around.
• Standalone IP assignment: for assets created outside the main build, such as a logo by a different designer, use a separate signed assignment. Because s 196(3) of the Copyright Act requires a signed writing, the standalone document is the only way to secure those rights.
• Change request form: a simple form that records scope, price and timeline changes, paired with the change control clause, so variations are captured in one place.
• Warranty holdback: retaining a percentage of the final payment until defects reported in the warranty period are fixed, which keeps the developer engaged after launch.
• Service level agreement: only where the developer hosts or supports the site, covering uptime, response times, patching and backups, with remedies if targets are missed.

How an Artificer Legal lawyer would review your website development agreement

A review of this document is mostly an exercise in priorities. We would start with the IP clause, because it decides whether the asset you are paying for is actually yours: the assignment should cover future works and subcontractors, carve out only genuinely pre-existing tools, and include moral rights consents. Next, the limitation of liability: we would push to carve out the IP indemnity, confidentiality and data breach liability from any cap, and resist a cap that applies to everything. Then we would check the scope and acceptance provisions for objective criteria, the termination and handover rights for a practical off-ramp, and the privacy clauses against your obligations under the Privacy Act, including APP 8 if the developer is overseas. Finally, we would look at the agreement through the unfair contract terms lens, because a standard form contract offered to a small business cannot simply exclude all liability. If you have already signed, we can still review the agreement and tell you which clauses are enforceable and which are vulnerable.

Who owns the site when the developer moves on

The clause that most often decides whether a website development agreement works is the IP assignment, and the detail that decides the clause is the signature. Under the Copyright Act, the developer owns what they create unless a signed written assignment says otherwise. Everything else in the contract, the scope, the price, the warranties and the exit rights, is about managing a project. The assignment is about owning the result, and it is the difference between a website you bought and a website you are renting from the developer, with their name still on the deed. When you review the agreement, find that clause first and check the signature line, because nothing else in the document can fix it later.

The website development agreement is the document that decides who owns the code and designs, how scope and price changes are managed, when you pay, what the developer promises, how you accept the work, what happens on termination, and how disputes and data are handled. A business client cannot always rely on the ACL consumer guarantees, so express warranties and a properly signed IP assignment carry the load, and the unfair contract terms regime limits what a developer can put in a standard form contract. Reviewing the agreement before signing, with the IP clause first, is the step that protects your business long after the site goes live.