Custom Software Development Agreements In New Zealand

Yes, you should have a written agreement before you pay a developer or agency to build custom software for your startup.

The more nuanced part is what that agreement needs to cover. A simple one-page quote might confirm the price, but it often won't deal with the issues that cause real pain later: unfinished features, missed milestones, source code access, bugs after launch and who actually owns the software.

If you're searching for a custom software development agreement in NZ, you're probably already at the exciting stage where your idea is turning into a real product. The goal is to keep that momentum going while making sure your business is protected from day one.

Do You Need A Custom Software Development Agreement?

Yes, if you're paying someone to build software, a website, an app, a platform or a key digital feature for your business, you should have a proper software development agreement.

This applies whether you're working with:

• a freelance developer
• a development agency
• a technical co-founder doing paid development work
• an offshore development team
• a contractor who will later provide support or maintenance

A written agreement gives you a shared roadmap. It should explain what is being built, when each part is due, what you'll pay, when you can reject work, and what happens if the build goes off track.

For example, say Aroha is launching a booking app for beauty salons. She pays a developer to build the minimum viable product. The developer delivers a login screen, a booking calendar and some basic admin tools, but not the payment integration or automated reminders Aroha expected. If the agreement only says build beauty booking app, it will be hard to show what was promised. If the agreement includes a detailed scope, milestones and acceptance criteria, Aroha has a much clearer position.

A good app development agreement also helps with investor conversations. If you want to raise capital, investors will usually want to see that your startup owns or has the right to use the software that drives the business.

What Should The Scope Of Work Cover?

It depends on your build, but your scope of work should be detailed enough that both you and the developer can tell when the work is finished.

This is where many software projects go wrong. You may have a clear idea in your head, while the developer is relying on a shorter technical description. The agreement should close that gap.

Core Features

Your scope should list the main features the developer will build. For example:

• user registration and login
• customer dashboard
• payment processing
• booking or ordering functionality
• admin portal
• email or SMS notifications
• reporting tools
• API integrations with third party systems and clear API access terms

Try to avoid broad phrases like marketplace functionality or AI tool without more detail. If a feature matters to your business model, spell it out.

What Is Not Included

Your agreement should also say what is excluded. This can be just as useful as listing what is included.

For example, you might say the developer isn't responsible for:

• copywriting or product descriptions
• graphic design outside approved screen designs
• ongoing hosting costs
• app store fees
• third party subscription costs
• search engine optimisation
• marketing automation setup

This avoids the awkward moment where you assume something is included and the developer sees it as extra paid work.

Technical Requirements

Your agreement should capture the technical basics, especially if your startup will rely heavily on the software. This might include:

• the programming language or framework
• hosting requirements
• database structure
• browser and device compatibility
• accessibility expectations
• security requirements
• performance targets, such as expected load times or user volumes
• requirements for backups and disaster recovery

You don't need to become a developer overnight. But if a technical point matters commercially, it shouldn't be left to a casual conversation.

Who Owns The Software IP In New Zealand?

It depends on what your contract says, because paying for custom software doesn't always mean you automatically own every part of it.

In New Zealand, copyright is protected under the Copyright Act 1994. Software code can be protected by copyright, and copyright ownership is separate from owning the finished product or paying an invoice.

Your agreement should clearly deal with software IP ownership. Usually, your startup will want to own the custom code, designs, documentation and other deliverables created specifically for your project once you have paid the agreed fees.

The agreement should also deal with things the developer may not be able to assign to you, such as:

• pre-existing code libraries the developer already owned
• open source components
• third party plugins or tools
• generic methods, know-how or development processes
• stock images, fonts or design assets licensed from someone else

For these items, you may not need ownership. You may just need a broad, ongoing licence to use them as part of your product. The key is to know what you own and what you're licensed to use.

Open Source Software

Open source software can be helpful, but it needs to be managed carefully. Some open source licences include conditions about disclosure, attribution or how the software can be combined with other code.

Your agreement can require the developer to:

• tell you which open source components are being used
• avoid open source licences that create problems for your commercial model
• keep records of third party code and licences
• confirm that use of those components doesn't stop you from commercialising the product

Trade Marks And Branding

Your software agreement usually won't be the main document for registering your brand, but it should still say who owns logos, icons, app names and design assets created during the project.

If your product name or logo will become valuable, you may also want to think about trade mark protection through IPONZ. A registered trade mark can help protect your brand as your startup grows.

How Do You Avoid An Unfinished Build?

You avoid an unfinished build by linking payment to clear milestones, testing steps and acceptance criteria, rather than paying everything upfront.

Software projects often change as you learn more about your users. That's normal. The problem is when change happens without any process, and both sides disagree about whether the original price still applies.

Milestones

A milestone is a defined stage of the project. For example:

• wireframes approved
• design prototype delivered
• user login and account setup completed
• payment system integrated
• beta version delivered for testing
• launch version delivered

Your payment schedule can then match those milestones. This gives the developer cash flow as work progresses, while helping you avoid paying most of the project fee before you have anything usable.

Acceptance Testing

Acceptance testing is the process for checking whether a milestone or deliverable meets the agreed requirements.

Your agreement should explain:

• how long you have to test the work
• how you must notify the developer of defects
• what counts as a defect
• how quickly the developer must fix defects
• when work is treated as accepted

Be realistic with timeframes. If your team needs seven business days to test a complex feature, don't agree to two days just to keep the contract moving.

Change Requests

A change request clause sets out how you approve extra work or changes to the scope.

It can say that changes must be documented and agreed in writing before the developer starts extra work. That written approval should cover:

• the change being requested
• any extra fees
• any impact on the timeline
• whether other features will be delayed or removed

This protects both sides. You don't get surprise invoices, and the developer doesn't get asked to do unpaid work that was never part of the original brief.

Should You Get Source Code Access?

Yes, if the software is custom-built for your startup, you should usually have a clear right to access the source code.

Source code is the human-readable code developers use to build and maintain software. Without it, you may struggle to fix bugs, move to another developer, add features or keep the product running if the relationship ends.

Your developer contract should say:

• where the source code will be stored, such as a shared repository
• when you get access
• whether access is read-only or full admin access
• what happens if invoices are unpaid
• what documentation must be provided with the code
• whether passwords, API keys and deployment instructions must be handed over

Some agencies prefer to provide source code only after final payment. That can be reasonable in some projects, but you should still be careful. If you only get access at the very end and the relationship breaks down mid-build, your startup may be left with limited practical control.

A middle-ground option is to require code to be committed regularly to a repository you can access, with ownership or full use rights taking effect as payments are made. The right approach depends on your payment structure, the developer's process and how business-critical the software is.

Passwords, Hosting And Admin Access

Source code is only one part of control. Your agreement should also cover access to the systems that keep your product running.

Make sure you know who controls:

• hosting accounts
• domain names
• app store accounts
• analytics tools
• email services
• payment gateway accounts
• cloud storage
• admin dashboards

Where possible, your business should own the main accounts, with the developer added as a user. This makes it easier to change providers or developers later without losing access to your own product.

What Happens After Launch?

It depends on your agreement, because launch is usually the start of your software's life, not the end of the developer's role.

After launch, you may need bug fixes, updates, hosting support, security patches, performance improvements and help responding to user feedback. If your agreement is silent, you may find that post-launch work is charged at a higher hourly rate or not offered at all.

Warranty Periods And Bug Fixes

Your agreement can include a warranty period for fixing defects that relate to the agreed scope. For example, the developer may agree to fix defects reported during an agreed period after launch, as long as the defect isn't caused by your changes, third party systems or misuse.

Be clear about the difference between:

• fixing a bug in an agreed feature
• building a new feature
• changing a feature because your business priorities have shifted
• fixing an issue caused by a third party platform or plugin

These categories often look similar in practice, but they have different cost consequences.

Maintenance And Support

If you need ongoing help, consider a separate support and maintenance agreement. This can cover:

• monthly support hours
• response times for urgent issues
• security monitoring
• software updates
• hosting support
• backup checks
• fees for extra work

If you process customer information through the software, privacy and security should be front of mind. The Privacy Act 2020 requires businesses to handle personal information carefully, including through the Information Privacy Principles and the notifiable privacy breach rules. Your agreement can require the developer to follow reasonable cybersecurity practices, keep data confidential and tell you quickly if there's a security incident.

If your software will be used by consumers, you should also think about your public terms, refund settings and customer promises. The Fair Trading Act 1986 prohibits misleading or deceptive conduct, and the Consumer Guarantees Act 1993 may apply to consumer-facing goods or services. If you're contracting with other businesses, some Consumer Guarantees Act protections can be contracted out of where both parties are in trade and it's fair and reasonable.

Hiring An Individual Developer

If you're hiring an individual developer, it depends on the real working relationship whether they're a contractor or an employee.

A developer contract startup teams use shouldn't just label someone an independent contractor and assume that settles it. New Zealand employment law looks at the real nature of the relationship, and the Employment Relations Act 2000 is the main legislation in this area. Recent changes, including the Employment Relations Amendment Act 2026 contractor gateway test, make it even more important to set up contractor arrangements carefully.

Your contract should match how you actually work together. Think about whether the developer can work for others, provide their own tools, control how the work is done, delegate or subcontract work, and take on commercial risk. If the arrangement looks more like employment in practice, you may need an employment agreement and to consider Holidays Act 2003 obligations such as annual holidays and other leave entitlements.

This is an area where tailored advice is worth getting early, especially if the person will work closely with your team over a long period.

Key Takeaways

• A custom software development agreement should do more than record the price. It should cover scope, milestones, testing, payment, IP, source code and support.
• Software IP ownership in New Zealand depends heavily on the contract, so don't assume paying the invoice gives you everything you need.
• Clear acceptance testing and change request processes help prevent arguments about unfinished builds and extra fees.
• Your startup should usually have a clear path to source code, documentation, passwords and key platform access.
• Post-launch support, privacy, security and consumer law issues should be considered before your product goes live.
• If you're hiring an individual developer, make sure the contractor or employee setup matches the real working relationship.

If you'd like help with your software development agreement, IP ownership clauses, source code access terms and post-launch support arrangements, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.