Software Development Contracts in New Zealand: What to Include

Software projects often go off track for the same reasons: the scope is vague, ownership of the code is assumed rather than written down, and everyone relies on emails or verbal promises instead of a proper contract. That is where founders and SMEs get caught. You might think a proposal, statement of work, or standard supplier terms are enough, only to find out later that the delivery dates are flexible, extra charges keep appearing, or the developer still owns the intellectual property.

A well-drafted software development contract should answer the practical questions before you sign: what is being built, when it must be delivered, who owns the code and related IP, how changes are approved, what happens if the project slips, and how liability is handled if something goes wrong. If you are hiring a developer, development agency, or technical contractor in New Zealand, these are the clauses that usually matter most.

Overview

Software development contracts set the commercial and legal rules for building, customising, maintaining, or integrating software. For New Zealand businesses, the real value is not just having a contract in place, it is making sure the contract matches how the project will actually run day to day.

A useful agreement should make the project workable, reduce arguments over scope and fees, and deal clearly with ownership, testing, data handling, and exit rights.

• A precise scope of work, deliverables, milestones, and acceptance process
• Pricing, payment triggers, change request procedures, and rules for extra work
• Who owns the source code, custom developments, documentation, and background IP
• Confidentiality, privacy, and data security obligations
• Warranties, service levels, support, maintenance, and defect fixing
• Liability caps, indemnities, exclusions, and what happens if the project fails
• Termination rights, handover obligations, and access to code or project materials at the end

What Software Development Contracts Means For New Zealand Businesses

For a New Zealand business, a software development contract is the document that decides whether your project is controllable or chaotic. Before you accept the provider's standard terms, you need to know whether the contract actually protects your budget, your timeline, and your ability to use the software once it is built.

These agreements are used in a range of founder situations. You may be commissioning a custom app, engaging a developer to build a client portal, paying an agency to integrate systems, or hiring a contractor to improve an existing platform. In each case, the contract needs to reflect the practical reality of the work.

Why a Proper Contract Matters

The main risk is assuming that technical discussions are enough. They are not. A detailed proposal may explain features, but it often says very little about ownership, delays, testing, defect fixes, or what counts as completion.

This matters even more where software is central to your business. If the platform supports your online sales, booking flow, internal operations, or customer database, delay or failure can affect revenue, customer relationships, and compliance obligations.

New Zealand businesses also need to think about the broader legal context. Depending on the arrangement, the contract may interact with:

• Intellectual property rights in code, designs, databases, and documentation
• Privacy obligations under the Privacy Act 2020 if personal information is collected, stored, accessed, or processed
• Fair Trading Act 1986 issues if performance claims, timelines, or technical capabilities are overstated in negotiations
• Consumer or service quality expectations in some settings, especially where standard service obligations or downstream customer commitments are involved
• Employment versus contractor classification issues if an individual developer is engaged directly and works in a way that looks more like an employee relationship

Different Types Of Software Development Arrangements

Not every development deal looks the same, and the contract should reflect the model you are using. Founders often sign the wrong style of agreement because the project sounds straightforward at the start.

Common software development contracts include:

• Fixed-price build agreements for a defined set of deliverables
• Time and materials agreements where work is charged by hourly or daily rates
• Master services agreements with statements of work for multiple projects
• Development and support agreements where build work continues into maintenance
• White label or outsourced development arrangements involving subcontractors
• SaaS customisation agreements where a platform provider also performs development work

Each model creates different risks. A fixed-price deal needs a very clear scope, while a time and materials deal needs strong controls around estimates, approval, and reporting. If support is included, the agreement also needs to say what service levels apply after handover.

Who Usually Signs These Contracts

On the customer side, this is often signed by a startup founder, operations lead, technology lead, or director of an SME. On the supplier side, it may be a development studio, software company, independent contractor, or specialist implementation business.

That sounds simple, but the identity of the contracting party matters. Before you sign, check whether you are contracting with the actual New Zealand company doing the work, an overseas parent, or an individual contractor. If the wrong entity signs, enforcing rights later becomes harder.

Legal Issues To Check Before You Sign

The clauses that matter most are the ones people tend to skim when the project feels urgent. Before you sign a contract or approve a statement of work, make sure the agreement answers the commercial points that usually lead to disputes.

1. Scope Of Work And Deliverables

The contract should say exactly what is being built. If the scope is vague, almost every later disagreement becomes harder to resolve.

At a minimum, the scope should cover:

• The software, modules, features, integrations, and environments included
• Any exclusions, assumptions, dependencies, and customer responsibilities
• Whether design, UX, testing, migration, training, documentation, hosting, or deployment are included
• The deliverables to be provided at each stage
• The timeline, milestones, and any critical dates

Terms like “MVP”, “industry standard”, or “full integration” often cause problems unless they are defined. This is where founders often get caught, especially where sales conversations were broad and optimistic.

2. Change Requests And Scope Creep

Software projects change. The contract should recognise that rather than pretending the original specification will stay fixed.

A good change control process usually sets out:

• How either party can request a change
• What information must be included in the request
• Who approves the change
• How the change affects cost and timing
• Whether work can begin before written approval is given

Without this process, the supplier may charge for work you thought was included, or the customer may expect extra features for no additional fee.

3. Fees, Payment Terms, And Budget Controls

The pricing clause should do more than state an amount. It should explain when fees are payable and what has to happen first.

Key points to check include:

• Whether the project is fixed-price, capped, or charged on a time and materials basis
• Deposit requirements and milestone payment triggers
• What records the developer must provide for hourly work
• Whether third-party costs, licences, cloud services, or subcontractor costs are included
• What happens if the project pauses or the timeline extends
• Interest, suspension rights, or late payment consequences

Before you spend money on setup, make sure the payment schedule matches actual delivery points. Paying too much too early weakens your leverage if the project stalls.

4. Intellectual Property Ownership

Ownership of the code should never be left to assumption. If the contract is silent or poorly drafted, you may not end up owning what you paid to build.

Software projects often involve several different IP categories:

• New custom code and bespoke functionality created for the project
• Pre-existing code, frameworks, tools, and libraries owned by the developer before the project began
• Open source components subject to separate licence terms
• Documentation, technical specifications, designs, and workflows
• Customer materials, data, branding, and content supplied into the project

The agreement should say clearly whether IP is assigned to the customer, licensed to the customer, or split between new and pre-existing material. If the supplier keeps ownership of background IP, the customer should still receive a licence broad enough to use, maintain, and adapt the final solution as needed.

If escrow, source code access, or repository access matters to your business continuity, deal with that expressly before you sign.

5. Acceptance Testing And Defects

You need a clear process for deciding whether the software has been delivered properly. Otherwise, completion becomes a moving target.

The contract should address:

• How testing is performed and by whom
• The length of any acceptance testing period
• What counts as a defect, minor issue, or material failure
• Whether deemed acceptance applies if no response is given in time
• How and when defects must be fixed

This is especially important where milestone payments depend on acceptance. Without objective acceptance criteria, the parties can end up arguing about whether the software is “good enough”.

6. Warranties, Support, And Service Levels

Many founders assume support is included after the build. Often it is not. The contract should say what happens after go-live, not just during development.

Look for clauses covering:

• Whether the software will conform to the agreed specification
• Whether services will be provided with reasonable care and skill
• The warranty period for defects after delivery
• Response and resolution times for support issues
• Maintenance windows, updates, and version compatibility

If your business depends on uptime or a customer-facing platform, generic support wording is rarely enough.

7. Privacy, Confidentiality, And Security

If the developer will handle personal information, privacy terms are essential. New Zealand businesses remain responsible for many privacy risks even where a third party is doing the technical work.

Depending on the project, the contract may need to cover:

• What personal information the supplier can access and why
• How data is stored, secured, and returned or deleted
• Whether data is transferred or accessed from outside New Zealand
• Confidentiality obligations for code, credentials, business information, and customer data
• Who must notify whom in the event of a security incident or privacy breach

Where the software touches customer records, employee information, or payment workflows, these provisions need careful contract review.

8. Liability, Indemnities, And Risk Allocation

Liability clauses decide who carries the financial risk when the project goes wrong. Standard supplier terms often limit the developer's exposure heavily, sometimes to a level that does not match the size of the project.

Check:

• Any cap on liability and whether it is tied to fees paid under the agreement
• Which losses are excluded, such as indirect loss, loss of profits, or loss of data
• Whether IP infringement, confidentiality breaches, privacy breaches, or wilful misconduct are carved out from the cap
• Any indemnities given by either party
• Whether the developer must hold appropriate insurance

You may accept a liability cap, but it should be commercially sensible. A low cap can leave a business carrying most of the project risk itself.

9. Termination And Exit

The end of the relationship needs just as much attention as the start. If the project fails, or the supplier relationship no longer works, the contract should let you exit in an orderly way.

Important points include:

• Termination for breach, insolvency, delay, or convenience
• What fees are payable on termination
• What work in progress, code, documents, and materials must be handed over
• Access to repositories, credentials, and environments
• Transition assistance to a new developer or internal team

Before you rely on a verbal promise that “we'll sort that out later”, make sure the handover mechanics are in written terms.

Common Mistakes With Software Development Contracts

The most common mistakes are not exotic legal issues. They are ordinary commercial shortcuts that create expensive disputes later. Before you sign, look for these pressure points.

Signing The Supplier's Standard Terms Without Negotiation

Standard terms are usually written to favour the provider. They may leave milestones unclear, keep IP ownership with the developer, and exclude liability for delays or performance issues.

That does not mean the terms are automatically unacceptable. It means they should be reviewed in the context of your project, your budget, and how business-critical the software is.

Relying On Proposals And Emails Instead Of The Contract

Founders often assume pre-contract discussions will fill the gaps. The trouble starts when the signed contract says something else, or says nothing at all.

If a feature, integration, deadline, or handover requirement matters, it should appear in the signed documents in a legally workable form.

Failing To Separate Background IP From Project IP

Not every part of the final product can or should be assigned to the customer. Developers often use pre-existing tools, templates, and libraries across multiple clients.

The better approach is to identify:

• What the developer already owned before the project
• What new materials are created specifically for your business
• What licence rights are needed so you can actually use the finished software without interruption

This avoids a false assumption that “we paid for it, so we own all of it”.

Ignoring Open Source Risks

Open source software can be useful and perfectly legitimate, but it should not appear in the project without thought. Some open source licences carry conditions that affect distribution, modification, or disclosure obligations.

If the project includes open source components, the contract should address disclosure and licence compliance responsibilities.

No Practical Acceptance Process

Projects often stall because the contract says delivery occurs at “completion”, but gives no objective test for what completion means. That leaves one side saying the project is done and the other saying it is not.

A staged acceptance process with specific criteria usually works better than broad language.

Weak Exit And Handover Rights

The problem is not only whether you can terminate. The problem is whether you can keep operating afterwards.

If the contract does not require source code delivery, repository access, technical documentation, and transition support where needed, changing developers can become costly and disruptive.

Overlooking Privacy And Security In Early Drafts

Privacy terms are often left to the end, especially in early-stage projects. That can be risky where the software handles customer accounts, employee details, or other sensitive information.

Data access, security standards, subcontractor use, and breach notification should be agreed before development starts, not after a problem appears.

FAQs

Do I need a software development contract if I already have a proposal and quote?

Usually yes. A proposal and quote may explain the commercial outline, but they often do not deal properly with IP ownership, liability, acceptance testing, privacy, confidentiality, or termination.

Who owns the software if my business pays for custom development?

That depends on the contract. Payment alone does not guarantee ownership of all code and related materials. The agreement should state whether IP is assigned to you, licensed to you, or split between custom work and the developer's background IP.

Can I use a time and materials contract instead of a fixed-price agreement?

Yes, if the project scope is likely to change or is difficult to define upfront. The key is having controls around estimates, approvals, reporting, and caps so the budget does not drift without oversight.

What should happen if the developer misses deadlines?

The contract should say what counts as delay, whether timelines are dependent on customer inputs, what remedies apply, and whether you can terminate if delays become material. Without those terms, delay can be frustrating but hard to manage contractually.

Does a New Zealand software development contract need privacy clauses?

If the developer will access or process personal information, privacy clauses are strongly recommended and often essential. The agreement should deal with use of data, security, breach reporting, and return or deletion of information at the end of the project.

Key Takeaways

• Software development contracts should clearly define scope, deliverables, milestones, testing, and payment triggers before you sign.
• IP ownership needs explicit drafting, especially where the project includes custom code, background IP, documentation, and open source components.
• Change request processes help control scope creep, extra charges, and timeline slippage.
• Privacy, confidentiality, and data security clauses matter whenever the developer can access personal or commercially sensitive information.
• Liability caps, indemnities, warranties, support terms, and defect obligations should match the commercial importance of the software to your business.
• Termination, handover, and transition assistance clauses are essential if you may need to move the project to another provider.

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