Web Design Contracts: Protect Your Digital Business for New Zealand Businesses

A web design project can go wrong long before the site goes live. New Zealand businesses often sign a short proposal, pay a deposit, and assume the details will sort themselves out later. That is where problems start. Common mistakes include leaving ownership of the website content unclear, relying on verbal promises about deadlines and revisions, and accepting a provider’s standard terms without checking who is responsible for privacy, third party tools, or ongoing support.

A clear web design contract helps you avoid expensive rebuilds, delayed launches, payment disputes, and arguments over who owns the finished work. It also gives designers and agencies a better way to manage scope creep and client expectations. If you are about to hire a developer, engage a designer, or send your own terms to a client, here is what to sort out before you sign.

Overview

Web design contracts set the ground rules for how a website project will be delivered, paid for, changed, and handed over. For New Zealand businesses, the main legal pressure points are usually scope, intellectual property ownership, payment milestones, delays, warranties, privacy responsibilities, and what happens if the relationship ends early.

• Define exactly what work is included, and what is out of scope.
• State who owns the design files, code, content, and final website.
• Set payment terms, deposits, milestone invoices, and late payment consequences.
• Explain revision limits, approval processes, and project timelines.
• Allocate responsibility for hosting, domains, third party licences, and plugins.
• Address privacy, data handling, and legal compliance for website functionality.
• Limit liability in a fair and enforceable way.
• Include termination rights, handover, and post-launch support terms.

What Web Design Contracts Means For New Zealand Businesses

A web design contract is the document that turns a loose project brief into a legally workable commercial arrangement. It matters whether you are a business hiring a freelancer, a startup engaging an agency, or a design studio supplying services to clients.

In practice, these contracts often cover more than just visual design. They may include UX work, development, copy, SEO basics, integrations, e-commerce functions, testing, training, hosting setup, maintenance, and content migration. If those moving parts are not written down properly, the parties can end up with very different ideas about what was bought and sold.

Why the contract matters so much

The main risk is not usually that there is no document at all. The bigger risk is a document that looks tidy but leaves out the commercial detail. A one page quote may confirm price and timing, but say nothing useful about ownership, changes, or delayed client feedback.

That gap becomes a problem when the project stalls or expectations shift. A client may think unlimited revisions are included. A designer may assume stock images, premium plugins, or copywriting are additional costs. Without clear written terms, both sides are exposed.

What New Zealand law does, and does not, do for you

General contract law in New Zealand can help enforce agreed terms, whether they are set out in a formal agreement, proposal, or accepted quote. But the law does not write the project details for you. If ownership, support, or deliverables are not properly described, you may still end up in a messy factual dispute.

Consumer style protections can also affect service businesses in some situations. For example, services supplied in trade may carry legal expectations around reasonable care and skill, reasonable fitness for purpose, and completion within a reasonable time where timing is not fixed. Those default positions are useful, but they are not a substitute for a tailored contract.

Marketing statements also matter. If you promise a client that a website will be ready by a certain date, rank on search engines, or integrate with a platform in a certain way, those statements can create risk if they are inaccurate or misleading. That is one reason project proposals and sales communications should match the final contract.

Who needs a web design contract

Any business paying for website work should use one, and any business supplying website work should have its own terms. This includes:

• Freelance web designers
• Digital agencies
• Developers building custom sites or online stores
• Marketing businesses offering website packages
• Startups hiring external designers before launch
• SMEs replacing or upgrading an existing website

If your website includes customer signups, online sales, forms collecting personal information, or integrations with payment providers, the contract should also reflect those extra legal and technical responsibilities. That does not mean the web design contract has to contain every privacy notice or e-commerce term in full, but it should make clear who is responsible for what.

Legal Issues To Check Before You Sign

Before you sign a web design contract, make sure the commercial promises match the legal wording. This is where founders often get caught, especially when they are moving quickly and relying on a provider’s standard terms.

1. Scope of work

The contract should say exactly what the designer or agency is delivering. If the scope is vague, disputes over price and timing usually follow.

A good scope should cover:

• Number and type of pages
• Design concepts or templates to be provided
• Custom development work
• Mobile responsiveness
• E-commerce functionality
• Integrations with booking tools, CRMs, payment gateways, or mailing platforms
• Content writing, image sourcing, and uploads
• SEO setup, analytics, and testing
• Training or handover materials

If something is excluded, say so clearly. For example, the contract might state that copywriting, logo design, legal policies, domain purchase, or plugin subscriptions are not included.

2. Intellectual property ownership

Ownership is one of the biggest pressure points in web design contracts. Do not assume paying for the work means you automatically own every element of the site.

The agreement should separate out different types of intellectual property, such as:

• Pre-existing tools, templates, code libraries, and processes owned by the designer
• New custom designs or code created specifically for the project
• Client supplied material, such as logos, photos, and text
• Third party assets, such as fonts, stock images, themes, and plugins

Some contracts transfer ownership of custom work only after full payment. Others give the client an IP licence to use the finished product while the designer keeps ownership of underlying methods or reusable assets. Either structure can work, but the wording needs to be clear.

If you are the client, check what files you will receive on completion. If you are the provider, check whether you are expected to hand over editable source files, admin credentials, design files, or repository access.

3. Payment terms and milestones

The contract should tie payment to a workable project plan. A deposit alone is not enough if the rest of the pricing model is unclear.

Look for:

• Deposit amount and when it is payable
• Milestone payments linked to specific deliverables
• Rules for billing additional work
• Late payment fees or suspension rights
• Whether third party costs are included or passed through
• What happens if the client pauses the project

If you are the supplier, avoid starting substantial work before the deposit is paid. If you are the client, avoid a payment structure that requires nearly all fees upfront before any tangible output is delivered.

4. Revisions, feedback, and delays

Most website disputes are really scope disputes dressed up as creative disagreements. Revision rules help contain that.

The contract should say how many rounds of revisions are included, how feedback must be given, and how long each party has to respond. It should also deal with delays caused by late content, missing approvals, or changing instructions.

This matters because a project can quietly drift for months if the client is slow to approve, or if the designer keeps making unpaid changes. A proper clause allows deadlines to move when dependencies are not met.

5. Privacy and personal information

If the website will collect personal information, privacy responsibilities should not be left to guesswork. This is especially relevant for enquiry forms, account registrations, booking systems, newsletters, and online stores.

The design contract should clarify who is responsible for:

• Preparing privacy disclosures and collection statements
• Choosing compliant third party tools
• Configuring forms and data storage settings
• Uploading cookies or tracking tools
• Responding to data access or correction requests after launch

A web designer is not automatically responsible for the client’s wider legal compliance, but the contract should avoid implying that legal review is included unless that is genuinely part of the engagement.

6. Warranties and legal promises

The contract should be realistic about what is guaranteed. Broad promises create unnecessary risk.

For example, a supplier may be willing to promise that work will be carried out with reasonable care and skill, and that the delivered site will materially match the agreed specification. That is very different from promising that the site will be uninterrupted, fully secure against all threats, or generate a certain level of sales.

Clients should also give warranties where appropriate, such as confirming they have the right to use any logos, images, text, or data they provide.

7. Liability limits and indemnities

Liability clauses often decide who carries the financial risk when things go wrong. They should be fair, clear, and matched to the project value.

A supplier may seek to cap liability to the fees paid under the contract, exclude indirect loss, and carve out issues caused by third party platforms or client changes. A client may push back if the cap is too low for a high value custom build.

Indemnities should also be drafted carefully. A broad indemnity can expose one party to losses far beyond the project fee. Before you accept the provider’s standard terms, consider a contract review to check exactly what losses you are covering and in what circumstances.

8. Termination and handover

Projects do not always finish neatly. The contract needs to say what happens if one party wants out.

Key questions include:

• Can either party terminate for convenience?
• What notice period applies?
• What fees are payable for work already done?
• Will partially completed work be handed over?
• When will access credentials and files be provided?
• Does the provider have to assist with transition to a new developer?

If handover is not addressed, a client may pay for a website but struggle to obtain practical control over hosting, domains, or backend access.

Common Mistakes With Web Design Contracts

The most common mistakes are preventable. They usually happen when business owners are trying to move quickly and treat the contract as admin rather than risk management.

Using a quote as the whole agreement

A quote can confirm pricing, but it rarely covers ownership, liability, or termination in enough detail. If the quote is the only document, the parties may end up arguing about issues that were never written down.

Assuming the client owns everything automatically

Payment and ownership are not always the same thing. If the contract is silent, there may be confusion about who owns the code, design system, graphics, or reusable components.

This is especially risky where agencies use existing frameworks, templates, or subcontractors. The client may think they are buying a fully owned custom asset, while the supplier thinks they are granting a limited licence.

Leaving third party tools out of the deal

Websites often depend on themes, plugins, hosting platforms, stock libraries, and software subscriptions. If the contract ignores them, no one is sure who pays, who holds the licence, or who is responsible when a tool stops working.

That can become a real problem after launch, when a plugin renews, a platform changes its pricing, or a licence was purchased under the designer’s account and cannot easily be transferred.

Relying on verbal promises

Founders often remember the sales call, not the contract wording. If someone said the website would be ready before a campaign date, include that milestone in the signed document. If someone promised training, migration, or support, put it in writing.

Before you rely on a verbal promise, ask for the proposal or agreement to be updated. That simple step can prevent a lot of frustration later.

Ignoring content responsibilities

Many website projects stall because no one clarified who was responsible for supplying copy, images, product information, or legal notices. The provider may be waiting for materials, while the client assumes content creation is included.

The agreement should say:

• Who supplies content
• What format it must be in
• Whether the provider will edit or upload it
• What happens if content is late or non-compliant

Not checking privacy and compliance assumptions

A website can collect leads, process customer details, or send marketing emails from day one. If the business assumes the designer has covered all legal compliance, and the designer assumes the business will handle it separately, important steps can be missed.

This is common with form notices, cookie tools, payment pages, and marketing integrations. The contract should set clear boundaries around legal responsibility.

Forgetting post-launch support

Going live is not the end of the project. Bugs, updates, and handover questions often appear in the first few weeks.

If support is included, the contract should say for how long and what type of issues are covered. If maintenance is excluded, the client should know that before launch, not after a problem appears.

FAQs

Who owns a website after a web designer is paid?

It depends on the contract. Some agreements transfer ownership after full payment, while others give the client a licence to use the site and keep certain underlying assets with the designer.

Do I need a written web design contract if I am working with a freelancer I trust?

Yes. Trust helps, but a written agreement still protects both sides on scope, payment, timing, revisions, and ownership. It is especially important before you spend money on setup or rely on a launch date.

Can a web design contract cover ongoing maintenance?

Yes, but it should say exactly what maintenance includes, how long it lasts, response times, and whether it is part of the project fee or a separate monthly service.

What if the project changes halfway through?

The contract should include a variation process. That usually covers how changes are requested, priced, approved, and how they affect the timeline.

Should a web designer be responsible for privacy compliance on the finished site?

Not automatically. A designer may help implement privacy features or notices, but the business operating the site usually remains responsible for its wider legal compliance unless the contract expressly says otherwise.

Key Takeaways

• A web design contract should clearly cover scope, timelines, revisions, payment, and termination.
• Intellectual property terms matter, especially for code, design files, content, and third party assets.
• Before you sign, check who is responsible for hosting, licences, privacy features, and post-launch support.
• Do not rely on verbal promises about deadlines, functionality, or included services.
• A short quote or proposal is often not enough for a meaningful website project.
• Clear handover terms help avoid disputes over files, access credentials, and control of the finished website.

If you want help with intellectual property ownership, scope and revision clauses, payment and liability terms, privacy responsibilities, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.