- Contractor or employee: the first decision
- What the development agreement needs to lock down
- Owning the code, the designs and the content
- Privacy and security when the site collects personal information
- The site's content and your obligations under the ACL
- Engaging a developer overseas
- A checklist for the week before you brief a developer
- Where a lawyer adds value before you sign
- The handshake that does not transfer copyright
Your website is where customers form their first impression, place orders and get support, and the developer who builds it will hold your brand, your code and often your customer data in their hands. What the engagement looks like on paper decides who owns the finished site, who is liable if it breaks, and what happens when the developer moves on. None of that is settled by paying the invoice. It is settled by the decisions you make before you brief anyone, and by the documents you sign.
Contractor or employee: the first decision
The way you engage the developer drives everything downstream: who owns the work, what tax and super obligations you carry, what leave and termination rights apply, and whether you can direct how the work is done. Since the High Court's decision in Construction, Forestry, Maritime, Mining and Energy Union v Personnel Contracting Pty Ltd [2022] HCA 1, where a comprehensive written contract governs the engagement, the classification question turns primarily on the terms of that contract rather than a broad, after-the-fact review of how the parties behaved. The agreement you sign is therefore the decisive document, and calling someone a contractor in an email will not survive a contract that reads like employment.
The consequences of the choice are concrete:
- Employees: You withhold PAYG tax, pay superannuation guarantee at 12 per cent, the rate that has applied since 1 July 2025 according to the ATO, provide leave and other minimum entitlements under the Fair Work Act 2009 (Cth), and you can direct the developer's day-to-day work.
- Contractors: You agree a scope, milestones and a fee. The developer invoices you, adds GST if registered, controls how the work is performed and carries their own leave and insurance arrangements. No PAYG withholding, no leave accrual.
- Super for contractors: A contractor does not automatically mean no super. The ATO requires super guarantee on payments to contractors who are engaged wholly or principally for their personal labour, which is common when a sole-trader developer does the work themselves.
- Sham contracting: Presenting a genuine employment relationship as a contracting arrangement is prohibited under the Fair Work Act and exposes you to penalties, so the label on the agreement has to match the reality of control and integration.
- Newer gig-work reforms: Recent Fair Work changes have extended some minimum standards to employee-like workers engaged through digital labour platforms. If you source developers through gig platforms, the classification question is less straightforward and worth specific advice.
There is also an ownership consequence. Copyright in work an employee creates in the course of employment vests in the employer automatically, while a contractor's work stays with the contractor unless it is assigned in writing. That difference is one of the most expensive mistakes in web projects, and it is covered next.
What the development agreement needs to lock down
A written agreement is the project's rulebook, and where a dispute arises it determines who wins. A website development agreement for a contractor should cover at least the following:
- Scope and deliverables: Describe exactly what is being built: pages, templates, integrations, content management setup, analytics, accessibility standards and anything else you are paying for. Ambiguity here is the single biggest source of scope disputes.
- Milestones and acceptance: Tie payment to defined milestones and include an acceptance process, for example a review window of five to ten business days after each stage is delivered, with a right to require fixes against the scope.
- Change control: Set out how changes are requested, priced and approved. Most projects drift because extra features are discussed in chat and never scoped. A statement of work that is signed off before work starts keeps pricing honest.
- Timelines and dependencies: Include realistic dates for design, development, content loading and go-live, and list what you must supply (brand assets, content, credentials, access) so that delays on either side are allocated fairly.
- Fees and invoicing: State whether the price is a fixed fee, time and materials, or a hybrid, with rates, caps and what is included. Tie invoices to milestones, set due dates, and confirm how GST is handled if the developer is registered.
- Late payment: Agree what happens if an invoice goes unpaid, such as interest or suspension of work. Keep any late-payment charge to a genuine estimate of your loss; courts will not enforce a term that is extravagant compared with the actual cost of late payment.
- Warranties: The developer should warrant that the work will be performed with reasonable care and skill and, to their knowledge, will not infringe third-party rights. A short defect-fix period, commonly 30 to 90 days after acceptance, is standard.
- Liability: Agree a cap on the developer's liability, often linked to the fees paid, and what kinds of loss are excluded. This is a commercial negotiation, and the cap should reflect the value of the project to you.
- Termination and handover: Allow termination for breach with a cure period and for convenience on payment for work done to date. On termination or completion, require handover of source code, credentials, design files, documentation and third-party licences.
Owning the code, the designs and the content
Copyright in computer code, design assets and written content is the legal engine of a website build, and Australian law has a default position that surprises many business owners. Under s 35 of the Copyright Act 1968 (Cth), the author of a work owns the copyright in it. For a developer working as an employee that default is displaced: work made under a contract of service belongs to the employer. For an independent contractor there is no such rule, so the developer owns everything they create unless the agreement says otherwise.
That is why the IP clause matters more than any other. To transfer a contractor's copyright to you, s 196 of the Copyright Act requires an assignment in writing signed by the developer. A line in the agreement saying "you will own all work product" may not be enough if it reads as a promise rather than an assignment, and a verbal assurance that the work is yours has no effect at all. The clause should state that all project IP is assigned to you on creation and on payment, and it should be signed before the work starts.
Three further points are worth flagging:
- Moral rights: The developer as author retains moral rights, including the right to be attributed and the right not to have the work treated in a derogatory way. Only individuals hold these rights. Under s 195AWA of the Copyright Act, a written consent from the developer covering the acts you will need, reproducing, modifying and adapting the code, prevents a later claim, but the consent must be in writing and related to specified acts and works.
- Background IP: Developers build on pre-existing frameworks, libraries and tools. The agreement should let them keep their background IP while granting you a perpetual licence to use it as needed for your site. Without that licence you may own the custom code but be unable to lawfully run the site it sits in.
- Third-party assets: Stock photos, fonts, icons and plugins come with licences that may not permit commercial use or sublicensing to you. Check that the licences cover your intended use, and that any paid assets are transferred or licensed to you as part of the handover.
Finally, keep the keys in your name. Register the domain, hosting and SaaS accounts in your business name, use a shared password manager, and require credential handover at go-live. It is surprisingly common for businesses to discover their site is held hostage by an agency account they cannot access.
Privacy and security when the site collects personal information
If the site collects names, emails, payment details or any other personal information, the Privacy Act 1988 (Cth) may apply to you. The main trigger is size: under s 6D of the Act, a business with annual turnover above $3 million is covered by the Australian Privacy Principles. Smaller businesses are generally exempt, but there are important exceptions. You are still covered if you trade in personal information, provide health services, handle credit information or fall within the other carve-outs in the Act, so the threshold is a starting point, not the whole answer.
If you are covered, the principles that bite hardest in a website project are:
- APP 1, transparency: You must have a clearly expressed and up-to-date privacy policy explaining what you collect, why, who you share it with and how people can contact you.
- APP 11, security: You must take reasonable steps to protect personal information from misuse, interference, loss and unauthorised access. For a website that means HTTPS, secure storage of API keys, least-privilege access and sensible password practices, and it extends to your developers while they hold your data.
- APP 8, cross-border disclosure: If the developer, their subcontractors or your hosting provider are overseas, or store data overseas, you must take reasonable steps to ensure they handle the information consistently with the APPs. Under s 16C of the Act their breaches can be attributed to you, so a developer in another country does not move the risk elsewhere.
- Data breach notification: If you are an APP entity, the Notifiable Data Breaches scheme requires you to notify the Office of the Australian Information Commissioner and affected individuals where a breach is likely to result in serious harm.
Enforcement has teeth. Interferences with privacy, including APP breaches, are civil penalty provisions under ss 13G and 13H of the Act, and the maximum penalties were lifted substantially in 2022, running to tens of millions of dollars for larger corporations. Even if you sit under the threshold, your customers expect the same standard, and a public breach damages trust regardless of the regulator's jurisdiction.
Put the developer's obligations in writing: a data processing schedule covering security standards, breach notification to you, use of subcontractors and deletion of data at the end of the engagement. And make sure admin access, hosting accounts and domain registrations are set up in your name, not the developer's, with credentials handed over securely at go-live.
The site's content and your obligations under the ACL
The Australian Consumer Law (the ACL) is Schedule 2 of the Competition and Consumer Act 2010 (Cth), and it reaches your website in two ways. First, everything your site says is conduct in trade or commerce. Under s 18 of the ACL, you must not engage in conduct that is misleading or deceptive or likely to mislead or deceive, which covers product descriptions, pricing, testimonials and performance claims. A claim like "fastest on the market" needs to be true and substantiated, because the ACL does not care whether the exaggeration was intentional.
Second, if you sell goods or services through the site, the consumer guarantees apply to your customers. Services must be rendered with due care and skill under s 60 of the ACL and reasonably fit for the disclosed purpose under s 61, and the guarantees cannot be contracted out of. Your refund and returns process, and the way you describe it, must line up with those rights.
One distinction is worth making. The consumer guarantees protect your customers, and they can also protect you if you buy the website build as a consumer, which generally means an acquisition under the value threshold or of a kind ordinarily acquired for personal or household use. A business-grade build is often outside that, which is exactly why the warranties in your development agreement, rather than the ACL, carry the weight. If your business is buying the site, negotiate the warranty and liability terms hard, because you may not have the statutory backstop.
Engaging a developer overseas
Many Australian businesses work with developers overseas, and the law allows it. The extra care is in the paperwork:
- Governing law and jurisdiction: Choose Australian law and an Australian forum in the agreement. It does not guarantee a local court will take the case, but it gives you the best chance of enforcing your rights at home.
- IP assignment: An assignment valid in Australia may not be valid where the developer is based. Some countries treat moral rights as inalienable, and others require different formalities, so check that the assignment works in the developer's jurisdiction, especially if they use subcontractors.
- Data: If personal information will be stored or accessed overseas, APP 8 applies and you remain accountable for how it is handled.
- Practicalities: Time zones, communication cadence and milestone reviews should be built into the project plan rather than assumed.
A checklist for the week before you brief a developer
Preparation before the brief is cheap; renegotiating after the work starts is not. A short run-through:
- Define the scope: the features you need now, the ones that can wait, and the standards you care about, such as performance, accessibility, SEO and integrations.
- Choose the engagement model and have the right agreement ready: a contractor agreement with an IP assignment, or an employment contract, plus a non-disclosure agreement for early discussions if you will be sharing commercially sensitive information.
- Map the IP: what you will own outright, what you will licence, and what third-party assets will be used.
- Plan privacy and security: draft your privacy policy, decide on cookie and analytics disclosures, and set out security requirements for the developer.
- Set realistic timelines and budget, and price change requests through the change control process.
- Agree the handover: source code, design files, documentation, credentials, training and post-launch support.
Where a lawyer adds value before you sign
Most of the work in this article is judgement, not paperwork. Whether a developer is truly a contractor, whether the IP clause actually assigns copyright, whether your privacy exposure justifies a data processing schedule, and whether the liability cap matches the risk of the project are calls that depend on the specifics of your business. An Artificer Legal lawyer can review the proposed agreement, redraft the assignment and privacy terms so they hold up, and tell you where the risk actually sits before you commit. That review is cheaper than a dispute about who owns the site after you have paid for it.
The handshake that does not transfer copyright
The most expensive misunderstanding in website projects is the belief that paying for the work makes it yours. Under Australian law it does not. Copyright stays with the developer unless it is assigned to you in a signed written document, and for a contractor that means a properly drafted IP clause, signed before the work begins, not a promise in an email thread. Everything else, the scope, the milestones, the warranties, the privacy terms and the handover, is built on that foundation.
The other points to carry with you: decide contractor or employee up front and let the contract match the reality, lock down scope and change control so the price does not drift, keep the domain, hosting and admin accounts in your name, get your privacy policy and data handling in order before the site goes live, and check that the claims on your site can be substantiated under the ACL.