What belongs in a web developer's terms and conditions

You have a client signed up, a deposit invoice ready to go, and a one-page proposal that says "standard terms apply" — except the terms don't exist yet, or they're a copy of a US template a friend sent you, or they're three years old and pre-date the day a client kept asking for "just one more" homepage revision. Whatever stage you're at, the document that decides whether you get paid, whether you own the code, and whether you carry the can for a content takedown is the same document: your terms and conditions.

For a web developer, the terms and conditions are the contract — they govern the supply of services once the client accepts a quote or signs an order form. They sit beneath the quote (which sets price and scope for one job) and displace the default position the law would otherwise impose: how copyright in the site is allocated, how long the client has to complain about defects, who carries the risk if a third-party plugin breaks the site. They are not a marketing document, not a privacy policy, and not a website-use agreement for visitors to the finished site. They are the agreement between you and the person paying you to build something.

Scope of work and what sits outside it

The scope clause is the single most-litigated paragraph in any web build, because the dispute is almost always "you said you would do X" / "no I didn't". The clause should anchor itself to a specific document — usually the accepted quote, proposal, or statement of work — and treat that document as the only definition of what is included. Anything not in the named document is out.

Two drafting choices matter here:

• Whether scope variations require written agreement or can happen through email confirmation. Email is more realistic for small jobs; written sign-off matters once the build is over a certain dollar value.
• Whether you build a deemed-acceptance mechanism for change requests — if the client asks for something outside scope, you respond with a variation quote, and silence for (say) five business days is treated as rejection rather than acceptance.

Common traps:

• Listing what is in scope without listing what is out of scope. "Five pages" is ambiguous if the client thinks landing page templates count as one page each. State explicitly that copywriting, stock imagery licensing, ongoing hosting, SEO work, and integrations with the client's existing CRM are out of scope unless named.
• Letting the proposal references roll forward into later projects. The terms should make clear that the scope document is the one attached to this engagement, not the last one.

Fees, invoicing, and stop-work rights

Set out when invoices issue, when they're due, what happens if they aren't paid, and whether you can charge interest. A deposit-on-acceptance / milestone / final-payment-on-launch structure is the most common shape and is worth spelling out in the clause rather than leaving it to the quote.

The clause that pays for itself is the suspension right: if an invoice is overdue by a defined period (commonly 7 or 14 days), you may suspend further work, refuse to deploy to production, or withhold transfer of files until the invoice is paid. Without this, your only remedy for non-payment is termination plus a debt-recovery action — slow and expensive for the amounts typically in dispute on a small web project.

Two drafting points:

• Distinguish suspension (work pauses, contract continues, time for delivery extends) from termination (contract ends). You want both available, in that order.
• If you charge interest on overdue amounts, the rate needs to be one a court will see as a genuine pre-estimate of cost rather than a penalty. A reference rate plus a margin (e.g. RBA cash rate plus a fixed percentage) reads more defensibly than a flat "20% per annum".

Variations and revision limits

Web projects scope-creep more than almost any other small-business engagement, because design feedback is subjective and clients underestimate how many opinions there are inside their own organisation. The variations clause should cap the number of design rounds at a stated number (commonly two or three), set an hourly rate for work outside that, and require variations to be quoted before they are performed.

The drafting choice that matters: whether additional revisions are billed by the hour at a stated rate, or quoted as a fixed amount per request. Hourly is simpler to draft, harder to negotiate over (clients dislike open-ended exposure). A fixed-per-request rate is friendlier to the client but only works if your revision rounds are predictable.

The trap to avoid is the "until satisfied" clause, sometimes inherited from older templates. A clause saying you will revise the design until the client is satisfied gives the client a one-sided veto on completion and undercuts every other clause in the document.

Approval, acceptance, and the end of the build

The approval clause defines the moment the build is complete. Without it, "done" is whatever the client says it is, which usually arrives months after launch with a list of new requests. The clause should set out a written notification of completion from you, a defined feedback window (often 5–10 business days), and a deemed-acceptance fallback if the client does not respond within the window.

Pair this with a defined snag-list scope — the client can raise items that are defects or in-scope corrections during the feedback window, but cannot use the window to introduce new requirements. New requirements go through the variations clause.

A short bulleted check on the standard pitfalls:

• No deemed-acceptance fallback — projects sit in limbo with the final invoice unpaid because no one has formally "signed off".
• Feedback window opens before launch — feedback gets mixed with normal back-and-forth and the moment of acceptance becomes unclear.
• No requirement that feedback be consolidated and in writing — five stakeholders email you contradicting requests and there is no record of what was accepted.

Intellectual property and ownership of the site

This is the clause clients read most carefully, and the one most often drafted by copy-paste from an overseas template. Under Australian law, the author of an original literary or artistic work is the first owner of copyright in it — that is the default position set by s 35(2) of the Copyright Act 1968 (Cth). For a web developer engaged as an independent contractor (not as the client's employee), copyright in the code, design, and any custom assets vests in you unless the contract assigns it across. The clause has to do that work explicitly — silence leaves the developer owning the site the client paid for, which is not what either side usually wants but is what the legislation produces.

The realistic structure is layered:

• Custom code, design, and content created for the client: assigned to the client on full payment of all amounts owing. The "on full payment" trigger lines up the IP transfer with the money and makes the assignment a meaningful lever during a payment dispute.
• Pre-existing tools, libraries, frameworks, and any reusable components: retained by the developer, with a perpetual licence to the client to use them as part of the delivered site. You do not want to assign your reusable form-builder to every client and end up with no IP to reuse.
• Third-party components (open-source libraries, paid plugins, fonts, stock imagery): governed by the third party's licence; the clause should make clear the client takes the site subject to those licences and is responsible for ongoing licence renewals.

The variant the client side will usually push for: assignment of everything on signing, regardless of payment status. Push back on this — assignment should be triggered by payment, not by signature.

The trap that costs the most: not mentioning third-party fonts. The client launches, swaps a font on the homepage to one they bought from a foundry on a single-site licence, and then later asks you to spin up a second domain pointing at the same site. You inherit the licence problem unless the clause says they don't.

Liability, warranties, and the consumer-law floor

The liability clause caps your exposure if something goes wrong — typically at the fees paid under the relevant engagement, or some multiple of them. This is standard and worth including, but it doesn't operate in a vacuum.

If your client is a "consumer" for the purposes of the Australian Consumer Law, the consumer guarantees apply. Since 1 July 2021 the threshold for goods or services to attract the consumer guarantees was raised to $100,000, so most small-business web projects sit inside the regime. The consumer guarantees — services rendered with due care and skill, fit for purpose, within a reasonable time — cannot be contracted out of, which means a clause saying "no warranties of any kind" is unenforceable to that extent. What the liability clause can validly do is limit the remedies available where the breach is not a major failure, and cap quantum.

The other piece is the unfair contract terms regime. Since 9 November 2023, unfair terms in standard-form small-business contracts are not just void — they attract civil penalties, and the small-business threshold was expanded to capture contracts with businesses of up to 100 employees or up to $10 million in annual turnover. Most web-developer clients sit inside that perimeter. Terms that are commonly flagged as unfair in standard-form contracts include unilateral variation rights, broad termination-for-convenience rights held only by the developer, and indemnities that are not reciprocal.

Confidentiality, data, and what happens to client material on your servers

Most web projects involve the client handing over assets, login credentials, draft copy, and sometimes customer data. The confidentiality clause should be mutual (you protect their confidential material, they protect yours), should carve out information that becomes public other than through your breach, and should survive termination for a defined period.

Where the project touches personal information — even a contact form on the finished site — the privacy obligations under the Privacy Act 1988 (Cth) sit on whoever is the APP entity, which is often the client rather than the developer. The clause should make that allocation clear and require the client to ensure any data they provide for testing has been lawfully collected.

Optional and situational clauses

• Hosting and post-launch support: only worth including if you genuinely offer them; otherwise pin a separate engagement to it. If included, define the response-time SLA in business hours rather than calendar hours.
• Domain name and registrar ownership: name the registrant explicitly. Developers who register domains in their own name "to make setup easier" create handover problems years later.
• Restraint on poaching: a short, narrow clause stopping the client from soliciting your contractors for the project term plus a defined tail. Restraints are read down where overdrawn, so keep the scope tight.
• Termination for convenience by the client: include if it is a commercial reality, but pair it with a kill fee that recovers committed costs and a percentage of unbilled work.
• Dispute resolution: a tiered clause (notice, then negotiation, then mediation, then court) keeps small disputes from escalating to litigation immediately.

Where Artificer Legal helps with web-developer terms

When we draft or review web-developer terms, the clauses we work on hardest are the ones that decide outcomes when something goes wrong: the scope-and-variations interface, the IP-on-payment trigger, the consumer-law-aware liability cap, and the suspension right for non-payment. We map those against the engagement profile — whether you do fixed-price brochure sites, ongoing retainers, or large bespoke builds — because the same clause looks different across those three. We also run the document against the unfair-contract-terms regime, because a standard-form template that worked in 2022 may contain terms that are now penalty-exposed. If you want a set of terms that does the work you need it to do without sitting on top of a regulator's risk list, we can draft from scratch or audit what you have.

The IP handover that waits for payment

If one clause in a set of web-developer terms decides more disputes than any other, it is the IP-on-payment trigger. Hand over the code on signature and you have given away the leverage that gets the final invoice paid. Hold it back until full payment and you have a contract that resolves itself.

A strong set of web-developer terms anchors the build to a defined scope document, ties variations to written quotes and a capped revision count, closes the build with a deemed-acceptance window, allocates IP layer by layer with assignment triggered by payment, caps liability inside the consumer-law floor, and reserves a suspension right for non-payment. Each of those clauses is doing a specific job; together they turn the proposal-to-launch arc into a contract that survives the parts of a project where clients and developers most often disagree.