Alex is Sprintlaw’s co-founder and principal lawyer. Alex previously worked at a top-tier firm as a lawyer specialising in technology and media contracts, and founded a digital agency which he sold in 2015.
Contents
Hiring a website developer can feel straightforward until the project starts slipping, costs increase, or you realise you do not actually own the code you paid for. New Zealand businesses often make the same mistakes: accepting a developer’s standard terms without reading the IP clause, relying on verbal promises about timelines and revisions, or assuming the developer will handle privacy, hosting, and third party licences as part of the job.
The problem is not just a delayed website. A poorly documented web development arrangement can affect your brand, your customer data, your ability to switch providers, and your rights if the project goes wrong. If your site is a core sales channel or operational tool, those risks can become expensive very quickly.
This guide answers the main considerations for engaging website developers in New Zealand, including what should go into the contract, who owns the work, how to deal with scope changes, what to check around privacy and ongoing support, and the mistakes founders commonly make before they sign.
Overview
A web development agreement should do more than state a price and delivery date. It should clearly allocate ownership, responsibilities, risk, and practical handover rights so your business is not dependent on assumptions once work begins.
For most New Zealand businesses, the legal issues are not complicated, but they do need to be written down properly before you sign and before you rely on a verbal promise about what the developer will deliver.
- define the project scope, deliverables, milestones, and acceptance process
- confirm who owns the code, designs, content, and other intellectual property
- set out payment terms, change request rules, and what happens if the project is delayed
- deal with third party software, plugins, fonts, stock images, and licence restrictions
- address privacy, data protection, data security, and access to any customer or business information
- clarify testing, bug fixes, warranties, maintenance, and post-launch support
- include exit rights, handover obligations, and access to hosting, domains, and admin credentials
- check liability limits, indemnities, and dispute resolution clauses
What Considerations for Engaging Website Developers Means For New Zealand Businesses
The main point is simple: if a developer is building or changing a key business asset, your agreement needs to protect your ownership, continuity, and commercial position.
For a New Zealand startup or SME, a website is often more than marketing. It may take orders, capture leads, hold customer information, integrate with inventory or booking systems, or connect to payment providers. That means the contract is not just about design preferences. It affects operations, customer trust, and legal compliance.
Your website may involve several legal layers
A business owner might think they are buying “a website”, but in practice the work often includes multiple components with different legal issues attached. These can include:
- custom code or templates
- graphic design and branding elements
- copy, images, video, and downloadable content
- domain name access and DNS settings
- hosting and server configuration
- customer forms and data collection tools
- third party plugins, apps, and software integrations
- ongoing support, updates, and security patches
If the contract treats all of that as one vague service, this is where founders often get caught. You may think you are paying for ownership of the whole setup, while the developer assumes some items are merely licensed, some are outside scope, and some stay under their control.
New Zealand legal context matters
New Zealand law does not require a special licence to hire a website developer, but normal commercial law principles still apply. The agreement should be clear enough to reduce disputes, and any statements made during sales discussions can still matter under the Contract and Commercial Law Act 2017 and the Fair Trading Act 1986 if they were misleading.
If the developer is supplying services in trade, consumer style protections may also affect the arrangement in some cases. For business to business projects, parties sometimes contract out of certain statutory protections where the legal requirements are met and both sides are in trade. Whether that is appropriate depends on the contract and the parties involved.
If your website collects personal information, the Privacy Act 2020 also becomes relevant. Even where the developer helps implement forms, analytics, customer accounts, or booking systems, your business usually remains responsible for how personal information is collected, used, stored, and disclosed.
The commercial reality is just as important as the legal wording
A good web development contract should reflect how the project will actually run. Before you sign, ask yourself practical questions such as:
- what exactly will be delivered, and in what format
- when can you test it and reject incomplete work
- who approves each stage
- what happens if your instructions change
- who pays for third party tools and recurring subscriptions
- who has access to analytics, hosting, CMS accounts, and domain registrars
- what happens if the relationship ends halfway through the project
If those matters are not covered, the main risk is not abstract legal uncertainty. The main risk is losing time, money, and control when you most need certainty.
Legal Issues To Check Before You Sign
Before you accept the provider’s standard terms, make sure the contract answers the operational questions that matter once the build begins.
1. Scope of work and deliverables
The contract should say exactly what the developer is doing. “Website design and development” is not enough on its own.
The scope should identify:
- number of pages or templates
- key functionality, such as e-commerce, booking, memberships, or integrations
- content responsibilities, including who supplies text and images
- platform or technology stack, such as Shopify, WordPress, Webflow, or custom code
- mobile responsiveness, browser compatibility, and accessibility expectations
- SEO related tasks if any are included
- testing requirements and launch deliverables
If you want particular features, they should be written into the agreement. Do not rely on a proposal call or email summary if the signed contract is broader or inconsistent.
2. Timing, milestones, and acceptance
Delivery dates should not be left as rough estimates if timing matters to your business. A contract can include milestones, review periods, dependencies, and a process for sign-off.
This is especially important if the website must be live before a product release, investor presentation, seasonal campaign, or customer rollout. If your input is required, the agreement should also state that delays in supplying content, approvals, or feedback can move the timeline.
Acceptance clauses matter because they determine when work is treated as complete. A sensible clause often covers:
- how you test the site
- how long you have to report defects
- what counts as a defect versus a new feature request
- when the developer must fix issues
- when a milestone or final delivery is deemed accepted
3. Intellectual property ownership
If ownership is unclear, you may not fully control the website you paid for.
This is one of the biggest considerations for engaging website developers. New Zealand businesses should check whether the agreement says ownership transfers to the client on payment, whether only some materials transfer, and whether the developer keeps rights in pre-existing tools, code libraries, frameworks, or templates.
Your contract should separate:
- new custom work created specifically for your business
- the developer’s pre-existing materials and methods
- third party software or licensed components
- your own business materials, such as logos, copy, product images, and brand assets
If there is a transfer of IP, the wording should be clear about when it happens. Many contracts say ownership only passes once all fees are paid. That can be reasonable, but you should also make sure you receive access and usable files at the right time.
4. Third party licences and dependencies
Many websites rely on software, fonts, themes, plugins, APIs, stock media, and payment tools owned by other parties. You cannot assume the developer can simply pass all of those rights to you.
Before you sign, check:
- which third party products will be used
- whether they are paid or free licences
- who is responsible for subscription costs
- whose name the licences sit under
- whether the licences are transferable if you move developers
- whether any tool has usage restrictions or compliance requirements
This point matters because a website can technically function at handover but still leave your business exposed if key plugins or integrations are licensed to the developer personally or through the developer’s agency account.
5. Privacy and data handling
If the developer will access customer details, employee information, account credentials, analytics, or confidential business material, your contract should deal with privacy and confidentiality directly.
For New Zealand businesses, the Privacy Act 2020 may be relevant where personal information is involved. The agreement should cover what information the developer can access, what they can do with it, what security steps are expected, and whether they can use subcontractors or offshore providers.
Practical points to include are:
- limits on access to live customer data
- requirements to keep credentials secure
- restrictions on copying or reusing data
- notification obligations if there is a suspected data incident
- return or deletion of data at the end of the project
6. Fees, payment terms, and change requests
A fixed fee does not help much if the contract lets scope creep turn into surprise invoices.
The agreement should say whether pricing is fixed, staged, hourly, or mixed. It should also explain when invoices are issued, whether deposits are refundable, and what happens if the project pauses.
Variation or change request clauses are essential. They should set out:
- how new requests are submitted
- who approves changes
- how changes affect price and timing
- whether the developer can refuse work outside scope
This is where many disputes start. A founder thinks they are asking for a minor tweak. The developer sees a new feature that requires extra design, coding, testing, and integration work.
7. Warranties, liability, and service standards
The contract should describe what the developer promises about the quality of the work, and what they do not promise.
No developer can honestly guarantee that a website will never experience bugs, outages, security issues, or compatibility problems. But the agreement can still require reasonable care and skill, compliance with the agreed specification, and a process for fixing defects within a stated period.
You should also review any liability cap or broad exclusion clause. Some standard terms try to exclude nearly all loss, even where delay or poor work causes a business interruption. Those liability clauses are not always appropriate for a project that is central to your revenue or customer experience.
8. Maintenance, support, and handover
Build work and ongoing support are not the same thing. If you need updates, backups, monitoring, or troubleshooting after launch, that should be dealt with expressly.
A proper handover clause can be just as important as the build itself. It should address:
- delivery of source files and code repositories where relevant
- admin access to CMS, hosting, domain, analytics, and connected services
- documentation for custom features
- handover assistance if you move to another provider
- final backup and asset transfer on termination
Without this, your business may end up dependent on one developer for basic access to its own website.
Common Mistakes With Considerations for Engaging Website Developers
Most web development disputes come from assumptions, not unusual legal loopholes.
Assuming payment equals ownership
Paying for a website does not automatically mean you own every element of it. Some parts may be licensed, some may remain the developer’s background IP, and some may only be accessible through third party subscriptions.
If ownership matters, and it usually does, the contract needs to say so clearly.
Relying on verbal promises
Founders often remember statements like “unlimited revisions”, “fully custom”, “SEO ready”, or “we’ll handle everything”. If those promises are not reflected in the signed agreement, proving what was actually agreed becomes much harder.
Before you sign, ask for key promises to be written into the scope, milestone schedule, or service description.
Using a vague scope
Vague wording creates room for disagreement later. If the site needs booking functionality, payment integration, multi-language support, custom reporting, or migration from an old platform, spell that out.
The more important the feature is to your business, the less it should be left to implication.
Ignoring data access and privacy issues
Businesses sometimes give developers full access to live systems and customer data without documenting limits. That creates risk if credentials are shared informally, if subcontractors become involved, or if the relationship ends badly.
Privacy and security obligations should be part of the contract, not an afterthought once the build is underway.
Failing to plan for the breakup
It may feel awkward to discuss termination and handover at the start, but this is exactly the right time to do it. If the project stalls, the agency changes direction, or the relationship sours, your business needs a clean path to recover files, accounts, and unfinished work.
The contract should explain what happens on termination, including payment for completed work, transfer obligations, and continued access to essential systems.
Accepting broad exclusions without thinking about business impact
Some standard terms say the developer is not liable for indirect loss, lost profits, downtime, third party failures, data loss, or security issues. Those exclusions may be heavily one-sided for a business that depends on the website for sales or customer service.
You do not always need to remove every limit on liability, but you should understand what risks your business is being asked to carry.
Forgetting who controls the infrastructure
One common founder mistake is letting the developer register the domain, host the website under the developer’s own account, or connect business-critical services using the developer’s email and login details. That can create major access problems later.
Where possible, core assets should sit in your business’s name, with the developer given the access they need to do the work.
FAQs
Do I need a written contract with a website developer in New Zealand?
Yes, in most cases you should have one. A written contract helps confirm scope, ownership, timing, payment, and what happens if the project changes or ends early.
Who owns the website once I pay for it?
It depends on the contract. Some agreements transfer ownership of custom work on payment, while others let the developer keep certain rights or rely on third party licences that are not fully transferable.
Can a developer use subcontractors or offshore team members?
They may be able to if the contract allows it. If privacy, confidentiality, or quality control matters to your business, the agreement should say whether subcontracting is permitted and what obligations still apply.
What if the developer misses the deadline?
Your rights depend on the contract terms, including milestone obligations, delay clauses, termination rights, and any limits on liability. That is why delivery dates and dependencies should be clearly documented before you sign.
Should my business or the developer hold the domain and hosting accounts?
Your business should generally control core accounts wherever possible. That makes handover easier and reduces the risk of losing access if the relationship changes.
Key Takeaways
- The key considerations for engaging website developers are scope, ownership, timing, payment, privacy, support, and exit rights.
- A website development agreement should clearly define deliverables, milestones, testing, and what happens when the project changes.
- Do not assume paying for the work means you own all code, designs, licences, and connected assets.
- Privacy, confidentiality, and access controls matter if the developer will handle customer data or business systems.
- Handover clauses are essential so your business can keep control of hosting, domains, admin access, and project files.
- Standard developer terms are often negotiable, especially around IP, liability, support, and termination.
If you want help with website development contracts, intellectual property ownership, privacy obligations, and handover terms, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.
Alex SoloCo-Founder
