Who Owns Code Written By A Freelance App Developer?

In New Zealand, you may own the code your freelance app developer writes for you if you commissioned and paid for it - but you shouldn't rely on that alone.

The safer answer is this: your app development agreement should clearly say your business owns the app code, designs and deliverables, and that the developer assigns the relevant intellectual property to you.

This can feel surprisingly technical when all you want is a working app. But getting it right early can make a big difference if you later raise capital, bring on a co-founder, sell licences to customers, put app terms and conditions in place, or rebuild the product with a new developer.

Let's break down what freelance app developer IP ownership looks like in NZ, and what your contract should cover before any code is written.

Who Owns Code Written By A Freelance Developer In New Zealand?

It depends, but under the Copyright Act 1994 there are rules that can give the person who commissions and pays for a computer program the first ownership of copyright, unless the parties agree otherwise.

That sounds helpful, and it often is. If you specifically engage a developer to build your app and you agree to pay them for that work, the default position may support your business owning copyright in the commissioned computer program.

But there are a few reasons you still need a written agreement.

• The developer may have used pre-existing code, templates, libraries or tools that they don't intend to transfer to you.
• The contract might say the developer keeps ownership and only gives you a licence.
• Some deliverables may not be pure computer programs, such as UI designs, icons, copy, wireframes, documentation, datasets or brand assets.
• Your developer might be overseas, where different default copyright rules apply.
• You may need proof of ownership for investors, grant applications, app store reviews, enterprise customers or future buyers.

So, while NZ copyright law gives you a useful starting point, a clear contract is still the best way to remove doubt.

For example, say Maia is building a booking app for hair salons. She pays a freelance developer to create the first version, but they only agree to the scope over email. Six months later, Maia wants another developer to rebuild part of the platform. The first developer says they own the reusable backend framework and Maia only paid for a licence to use it. Even if Maia has arguments under NZ copyright law, she's now spending time and money untangling ownership when she should be scaling the product.

Why Is Paying The Developer Not Enough?

Paying the developer isn't enough because payment doesn't always tell you exactly what rights have moved from the developer to your business.

A payment invoice can show that you bought development services, but it isn't a software development agreement. It usually won't deal with the finer points that matter for a software product, such as:

• whether ownership transfers when work is created, delivered or fully paid for
• whether the developer keeps any reusable tools, frameworks or background IP
• whether you can modify, commercialise, sublicense or sell the app
• whether open source components can be used in your product
• whether the developer can reuse similar code for another customer
• what happens if the project ends before launch

These questions matter because app code is rarely one neat thing. It may include front-end code, backend code, databases, APIs, design files, prototypes, testing scripts, deployment settings, analytics integrations, plug-ins and written documentation.

If your contract is silent, you may still have rights, but you may also have gaps. Those gaps can become awkward when someone asks you a simple question: does your company actually own the product?

Ownership Versus A Licence

Ownership and a licence are different.

If your business owns the IP, you can usually control, change, commercialise and transfer it, subject to any third party restrictions.

If your business only has a licence, you can use the IP within the limits of that licence. A licence might be broad, narrow, permanent, revocable, exclusive, non-exclusive, paid, free, transferable or non-transferable.

A licence can still be useful. For example, your developer may need to keep ownership of their own reusable admin dashboard or deployment tool, while giving you a permanent licence to use it inside your app. The key is that your agreement should say this clearly.

What Should Your App Development Agreement Say About IP?

Your app development agreement should clearly assign the project IP to your business and carve out anything the developer keeps.

A good software developer contract in NZ shouldn't just say that you own the app. It should explain what that means in practical terms.

Project IP

Your contract should define the project IP broadly enough to cover everything the developer is being paid to create for your business.

This might include:

• source code and object code
• UI and UX designs
• wireframes, prototypes and mockups
• graphics, icons and other visual assets
• database structures and schemas
• technical documentation and user guides
• APIs and integrations created for the project
• testing materials, scripts and configuration files

The assignment clause should say the developer assigns to your business all rights, title and interest in the project IP. It should also cover future rights, updates and improvements created during the project.

Depending on the deal, ownership might transfer as work is created, on delivery, or once you have paid the relevant invoice. If the developer wants assignment only after payment, you may still want a licence to use delivered work if there's a payment dispute or the project ends part-way through. This depends on your bargaining position and the project risk.

Background IP

Your developer may bring their own existing materials to the project. This is common and not automatically a problem.

Background IP might include:

• code libraries the developer already had
• templates and boilerplate code
• internal tools
• development frameworks
• generic modules used across multiple client projects

If the developer is keeping ownership of background IP, your agreement should give your business a broad enough IP licence to use it as part of your app. That licence should usually allow you to host, operate, maintain, modify and commercialise the app.

If that licence is too narrow, you could own the custom code but still be unable to run the product properly.

Further Assurance

Your agreement should also include a practical follow-up obligation. If you need the developer to sign extra documents later to confirm ownership, they should have to help.

This can be useful if you're applying to register a trade mark with IPONZ, dealing with an investor's due diligence questions, or moving the code into your company's repository.

How Do Moral Rights Affect Your App?

Moral rights may matter for some app deliverables, even though they aren't usually the main issue for pure software code.

Under the Copyright Act 1994, creators can have moral rights in some copyright works. These rights are separate from copyright ownership. They can include rights around attribution and treatment of the work.

In practice, moral rights are more likely to come up for things like:

• illustrations and icons
• visual designs
• copy and content
• videos, animations or audio
• documentation or training materials

Computer programs are treated differently from many creative works, so moral rights may not apply in the same way to code. But if your developer is also creating design assets, written material or other creative deliverables, it's still worth covering.

Moral rights generally can't be assigned like ordinary copyright. Instead, your contract can include consents and waivers where allowed. This helps your business edit, adapt, rebrand, combine or commercialise the deliverables without needing approval each time.

For example, if your developer creates app illustrations and later you change the colour palette, crop icons for a marketing campaign, or remove the developer's name from public credits, you don't want those everyday product decisions to trigger an argument.

What About Open Source Code And Third Party Tools?

You can use open source code and third party tools in an app, but your agreement needs rules around what the developer can include and what they must disclose.

Most apps use some open source components. That's normal. The risk isn't open source itself. The risk isn't knowing what has been used or whether the licence terms fit your commercial plans.

Some open source licences are permissive, such as MIT or Apache-style licences. Others can include stronger sharing obligations, such as GPL or AGPL-style licences. Depending on how the code is used, these obligations may affect whether you need to release parts of your own source code or meet other conditions.

Your app development agreement should require the developer to:

• get your approval before using certain open source components
• keep a list of all open source and third party materials used
• tell you the licence terms that apply
• avoid components that would force disclosure of your proprietary code, unless you agree
• make sure third party tools are used within their licence limits
• hand over dependency lists and package files at the end of the project

Third party tools can also create commercial issues. For example, your app might rely on paid APIs, payment platforms, map services, analytics tools, AI tools, app store accounts or cloud services. You need to know who owns those accounts, who pays for them, and whether your business can keep using them after the developer's work ends.

If your app handles personal information, you should also think about the Privacy Act 2020 and whether you need a privacy policy. Your developer may need rules around access to test data, customer data, security practices and deletion of information when the project ends.

What Should Handover, Access And Contractor Clauses Cover?

Your agreement should make handover simple, because owning IP is only useful if you can actually access, run and maintain the app.

Many app projects go wrong not because the IP clause is missing, but because the business can't get the practical materials it needs when the developer leaves.

Handover Materials

Your handover clause should require the developer to give you everything reasonably needed to continue the project.

This often includes:

• source code in a repository your business controls, and any agreed source code escrow process
• admin access to hosting, cloud, deployment and database systems
• build instructions and deployment notes
• environment variables and configuration details
• API keys or a secure process for replacing them
• design files, not just exported images
• technical documentation
• login details for project tools, where appropriate
• a list of third party services and licence terms

For security, you shouldn't rely on the developer's personal accounts. Where possible, use accounts owned by your company and grant the developer limited access. If your company is registered with the Companies Office and has an NZBN, use the correct company name in contracts and key platform accounts so the ownership trail is clean.

Subcontractors

If the developer uses subcontractors, your agreement should say they can only do so with your approval, or at least that the developer remains fully responsible for their work.

You also need the developer to make sure each subcontractor assigns IP and gives moral rights consents where needed. Otherwise, you may end up with a clean-looking agreement with the main developer, but a missing link in the ownership chain.

Contractor Status

If you're hiring the developer as a contractor, your contract and working relationship should match that arrangement.

Employees and contractors are treated differently. For employees, copyright in work created in the course of employment will often be owned by the employer unless agreed otherwise. For contractors, you rely more heavily on commissioning rules, IP assignment wording and the actual deal between you.

The Employment Relations Act 2000 also matters when someone is labelled as a contractor but works more like an employee. From 2026, changes introduced through the Employment Relations Amendment Act 2026 include a contractor gateway test for some arrangements. In practical terms, your written contract, the level of control you exercise, how the person works, and how the arrangement operates in real life can all matter.

This doesn't mean you can't use freelance developers. It means your contractor agreement should be clear, and your day-to-day setup should match what you've agreed.

Common Mistakes To Avoid

A few mistakes come up again and again in app development projects.

• Using a proposal instead of a contract: A quote or proposal usually deals with price and scope, but not ownership, open source, confidentiality or handover in enough detail.
• Assuming GitHub access equals ownership: Access to a repository doesn't always prove your business owns the code.
• Letting the developer control all accounts: If hosting, app store, analytics or cloud accounts sit under the developer's name, handover can become messy.
• Forgetting design and content: Your app is more than code. Make sure designs, copy, icons and documentation are covered too.
• Ignoring open source: You need a record of what has been used and what licence terms apply.
• Leaving it until fundraising: Investors often ask who owns the product. It's much easier to answer if your paperwork is already in order.

Templates can be a useful starting point, but app development documents work best when they're tailored to how your product is being built and commercialised.

Key Takeaways

• In NZ, commissioning and paying for a computer program may support your ownership under the Copyright Act 1994, but a written agreement is still essential.
• Your app development agreement should include a clear contractor IP assignment clause covering code, designs, documentation and other deliverables.
• Background IP, third party tools and open source components should be identified and licensed properly so you can run and commercialise the app.
• Moral rights consents and waivers can help you edit, adapt and rebrand creative deliverables without unnecessary friction.
• Handover clauses should cover source code, accounts, credentials, documentation, deployment materials and third party service details.
• If you're using a contractor, make sure the written agreement and the real working relationship line up, especially with the 2026 contractor gateway changes in mind.

If you'd like help with your app development agreement, contractor IP assignment clauses, open source terms and practical handover obligations, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.