Website Development Agreement: Handover Checklist

Launching a new website is exciting, but the last few weeks can get messy if the handover details aren't clear. You might be dealing with final design tweaks, unpaid invoices, login access, hosting questions and a client who wants to know exactly when the site will go live.

A good website development agreement in NZ does more than describe the build. It sets up a smooth launch by spelling out milestones, testing, ownership, content responsibilities, hosting access and support after go-live.

Whether you're the developer or the client, the aim is simple: everyone knows what is being delivered, when it's accepted, who owns what and what happens next.

Do You Need A Website Development Agreement In NZ?

Yes, if you're building a website for a business, you should have a written website development agreement before work starts.

A written agreement helps you avoid the most common launch problems: unclear scope, moving deadlines, unpaid invoices, missing content, confusion over copyright and last-minute access issues. It also gives both sides a practical reference point if the project changes.

Your agreement doesn't need to be full of legal jargon. It should clearly answer questions such as:

• What pages, features, integrations and any custom software are included?
• What is outside scope and charged separately?
• When does the client need to provide content, feedback and approvals?
• How many revision rounds are included?
• Who owns the website, code, designs, copy, images and domain name?
• What happens if the launch date moves?
• What support is included after the site goes live?

This is especially useful if the website involves eCommerce, booking systems, memberships, payment gateways, analytics, email marketing or customer databases. Those projects often touch on privacy, consumer law, intellectual property and software development issues.

The Fair Trading Act 1986 can also matter here. If you're a developer, your proposal and agreement shouldn't overpromise what the website will do, such as guaranteed search rankings or sales outcomes. If you're the client, the agreement should capture the promises you're relying on before you pay the deposit.

What Should A Web Developer Contract Cover?

A web developer contract should cover the project scope, payment structure, responsibilities, testing, launch process, IP ownership and post-launch support.

Think of it as both a legal document and a project management tool. If the agreement is too vague, the practical parts of the build are usually where the tension starts.

Website Development Agreement Outline

Here's a useful fill-in outline for a web design contract in NZ. This isn't a finished legal document, and it should be tailored before you use it, but it gives you a strong starting structure.

1. Parties: Write the legal names, NZBNs where relevant, contact details and who can approve changes.
2. Project Scope: List the pages, templates, features, integrations and deliverables included in the price.
3. Out Of Scope Items: Say what isn't included, such as copywriting, photography, paid plugins, SEO campaigns or extra revision rounds.
4. Milestones And Timeline: Set out key dates for design, development, testing, launch and content delivery.
5. Fees And Payment: Record the deposit, milestone payments, final payment trigger and any late payment terms.
6. Client Responsibilities: Cover content, brand assets, logins, approvals, legal policies and timely feedback.
7. Testing And Acceptance: Explain how defects are reported, what counts as a defect and when the site is accepted.
8. Intellectual Property: State what is assigned, what is licensed and when transfer happens.
9. Hosting, Domains And Access: Record who controls accounts, where the website is hosted and what access is handed over.
10. Maintenance And Support: Set out warranty fixes, ongoing support, response times and excluded work.
11. Confidentiality And Privacy: Cover business information, customer data and access to systems.
12. Termination: Explain what happens if either side ends the project before launch.

Templates often miss the details that matter most to a real project, especially around IP, hosting access and acceptance testing. If the website is business-critical, getting the agreement tailored early can save a lot of awkward conversations later.

How Should Milestones, Payments And Acceptance Testing Work?

Milestones should match real project stages, payments should be tied to those stages, and acceptance testing should give the client a clear period to check the work.

For example, say Hana runs a Wellington skincare brand and agrees to pay $12,000 plus GST for a new Shopify website. The agreement might say:

• 30% deposit before work starts: $3,600 plus GST
• 40% when the approved design is built on a staging site: $4,800 plus GST
• 30% when acceptance testing is complete and before launch: $3,600 plus GST

The agreement could give Hana 5 business days to test the staging site and report defects in writing. If she doesn't respond within that period, the site is deemed accepted unless there's a serious fault that stops key functionality from working.

This kind of clause keeps the project moving, but it needs to be fair. A client should have a genuine chance to test the website. A developer shouldn't be left waiting indefinitely because feedback hasn't arrived.

What Counts As A Defect?

Your agreement should separate defects from new requests. A defect is usually something that doesn't match the agreed scope, approved design or required functionality. A new request is something extra, even if it would improve the site.

For instance:

• Defect: The checkout button doesn't work on mobile, even though mobile checkout was included.
• Defect: The contact form submissions aren't reaching the nominated email address.
• New Request: The client now wants a loyalty programme integration that wasn't in the scope.
• New Request: The client wants a third design concept after approving one concept and two included revision rounds.

A clear change request process helps here. It can require written approval for extra work, extra fees and any timeline changes before the developer starts.

Who Is Responsible For Website Content, Privacy And Legal Pages?

The agreement should say exactly who is responsible for providing, checking and approving website content, including privacy notices and customer-facing terms.

Content delays are one of the biggest causes of website launch delays. If you're the developer, you don't want the launch date to depend on copy, images or product descriptions that never arrive. If you're the client, you don't want the developer to publish placeholder content or old copy without approval.

Your agreement should cover:

• Who supplies copy, images, videos, product descriptions and brand assets
• When content must be provided
• What format the content should be in
• Who checks spelling, pricing, promotions and product details
• Who confirms that images, fonts, icons and videos are licensed for use
• Who prepares or updates the Privacy Policy, Website Terms, eCommerce Terms or booking terms

For New Zealand businesses, the Privacy Act 2020 is especially relevant if the website collects personal information, such as contact form entries, account registrations, newsletter sign-ups, bookings or order details. Your website should explain what personal information is collected, why it's collected, how it's used, who it may be shared with and how people can contact the business about privacy.

If the website sells to consumers, the Consumer Guarantees Act 1993 and Fair Trading Act 1986 may also affect what the business says about refunds, delivery, guarantees, pricing and product claims. A website build agreement won't replace those customer-facing terms, but it should make clear who is responsible for supplying legally accurate content.

Who Owns The Website After Handover?

It depends on the agreement, because website ownership can be split between code, design, copy, images, content management system access, plugins and domain names.

This is where many projects go wrong. Paying for a website doesn't always mean the client owns every underlying asset. Under the Copyright Act 1994, copyright ownership depends on the type of work, who created it, whether they were an employee or contractor, whether it was commissioned, and what the contract says. Website projects often involve several different copyright works, so the safest approach is to write the ownership position clearly.

A strong website ownership agreement in NZ should deal with:

• Custom Code: Whether it's assigned to the client or licensed for use.
• Design Files: Whether source files are included or only the final website is handed over.
• Copy And Images: Who owns or licenses written content, photography, video, icons and graphics.
• Developer Tools: Whether the developer keeps ownership of pre-existing code, frameworks, snippets or internal tools.
• Third-Party Assets: Which plugins, fonts, themes, stock images or software licences the client must maintain.
• Moral Rights: Whether creators give the consents needed for the client to use and modify the work without needing fresh approval each time.

Many agreements use a practical compromise: the client owns the final custom deliverables after full payment, while the developer keeps ownership of pre-existing tools and grants the client a licence to use them as part of the website.

Trade marks are different from copyright. If the website includes your brand name or logo, you may want to check IPONZ to see whether your trade mark can be registered or whether someone else already has rights that could cause problems.

What Should Be Included In A Website Handover Checklist?

A website handover checklist should cover every login, asset, setting and support obligation the client needs to run the site after launch.

The handover shouldn't be a rushed email with a password and a goodbye. It should be a clear process that happens after acceptance testing and final payment, or at the point your agreement specifies.

Launch-Ready Handover Checklist

• Domain Name: Confirm who the registered holder is, which registrar manages it and who has admin access.
• Hosting: Record the hosting provider, plan, renewal dates, server access and billing responsibility.
• CMS Access: Hand over administrator access to WordPress, Shopify, Webflow or the relevant platform.
• Source Files: Provide agreed design files, theme files, code repositories or documentation.
• Plugins And Licences: List paid plugins, themes, fonts, apps and who pays renewals.
• Email And DNS: Confirm DNS settings, email records, SPF, DKIM and any redirect rules.
• Analytics: Transfer or invite access to analytics, tag manager, search console and advertising pixels where agreed.
• Backups: Explain where backups are stored, how often they run and how restoration works.
• Security: Record SSL certificates, user roles, two-factor authentication, any penetration testing and update responsibilities.
• Training: Provide agreed training notes or a walkthrough for common website tasks.
• Legal Pages: Confirm Privacy Policy, Website Terms and eCommerce Terms are uploaded if they're part of the scope.
• Post-Launch Support: State the warranty period, included fixes, response times and how to request help.

For privacy, be careful with shared logins. If the developer has access to customer data, order histories, booking information or email lists, the agreement should include confidentiality and privacy obligations. Communications with some legal service providers may not be protected by legal professional privilege, so if privilege is critical for a sensitive matter, you should get advice from a New Zealand legal practitioner.

If the developer uses subcontractors or freelancers, the contract or subconsultant agreement should require them to protect confidential information and assign or license their IP properly. From 2026, changes to the Employment Relations Act 2000 include a contractor gateway test that may affect how some contractor relationships are assessed. If your contractor arrangements are central to your business model, it's worth getting tailored advice.

Key Takeaways

• A website development agreement in NZ should cover the build, the launch and what happens after handover.
• Milestones, payment triggers and acceptance testing help both sides avoid open-ended projects.
• Content responsibility should be clear, especially for privacy notices, legal pages, product claims and customer-facing terms.
• Website ownership can be split across code, design, content, plugins, licences and domain access, so write it down.
• A proper handover checklist should include hosting, domains, CMS access, source files, analytics, backups, security and support.
• If you're using a template, have it tailored to the actual project before you rely on it.

If you'd like help with your website development agreement, IP ownership clauses, handover checklist or website terms and privacy documents, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.