Who Owns Code, Designs and Other Client Work in a New Zealand App Development Agency?

If you run an app development agency in New Zealand, or you hire one, ownership of the work can become messy fast. Founders often assume that paying for software means they automatically own the code. Agencies often assume their standard terms let them keep reusable components, but never explain that clearly. Another common mistake is focusing on delivery dates and pricing while ignoring who owns designs, source code, APIs, databases, documentation and third party assets.

That is where disputes usually start, often right when a client wants to switch developers, raise investment, sell the business or launch a new product. If ownership is unclear, the client may not be able to use, modify or sell what they paid for, and the agency may lose control of valuable internal tools or frameworks.

This guide answers the practical question at the centre of many software projects: who owns creative work in an app development agency relationship in New Zealand, and what should your contract say before you sign?

Overview

Ownership of app development work in New Zealand usually depends on contract terms, not assumptions. Different parts of a project can also be treated differently, so one agreement might give a client ownership of bespoke deliverables while the agency keeps its pre-existing tools, libraries and know-how.

• Whether the work was created by an employee, contractor or subcontractor
• What the services agreement says about intellectual property ownership and assignment
• Whether the agency used pre-existing code, templates, frameworks or third party assets
• Whether the client receives full ownership, a licence to use, or something more limited
• When ownership transfers, for example on creation, on payment, or on signed assignment
• Whether moral rights consents, confidentiality terms and handover obligations are covered
• What happens if the relationship ends before the project is completed

What Who Owns Creative Work App Development Agency Means For New Zealand Businesses

The short answer is this: the person or business that creates the work does not always end up being the person or business that owns it, but ownership only shifts if the legal arrangements actually do that.

For New Zealand businesses, this issue sits mainly in contract law and intellectual property law. In plain English, you need to separate out who made the work, what kind of work it is, and what the agreement says happens to it.

What counts as creative work in an app project?

In an app development agency context, “creative work” is much broader than the app’s final codebase. A single project may include multiple valuable assets, each with different ownership and usage rules.

That often includes:

• source code and object code
• wireframes, user flows and UX research outputs
• UI designs, icons, illustrations and brand-adjacent design assets
• technical architecture, schemas and specifications
• databases and data structures
• API integrations and middleware
• copy, onboarding text and help content
• project documentation and manuals
• test scripts and deployment materials
• internal agency templates, starter kits and reusable modules

A founder may think they are buying “the app”, but legally that phrase is too vague. If your contract does not spell out what sits inside that bundle, the parties can walk away with very different expectations.

Does paying for the work mean the client owns it?

No, not automatically. Payment alone does not always transfer intellectual property rights in bespoke software, designs or related project materials.

This is where founders often get caught. A client pays a substantial build fee, receives a live product, then later discovers the contract only granted a limited licence to use the app for internal purposes, or said nothing clear enough to transfer ownership at all.

If you are the client, you should not assume that an invoice, statement of work or project plan gives you ownership. If you are the agency, you should not assume your business keeps ownership unless your terms say that clearly and your workers have assigned rights to you properly.

Employees, contractors and subcontractors matter

Ownership becomes more complicated when multiple people contribute to the project. Agencies commonly use a mix of employees, freelancers and specialist subcontractors, especially for design, QA, backend work or DevOps.

That matters because your promise to the client is only as good as the rights you actually control. If a contractor created a key feature and never assigned intellectual property to the agency, the agency may not have full rights to pass on to the client.

Before you sign a contract with a client, an agency should make sure its internal documents cover:

• employee intellectual property ownership clauses
• contractor IP assignment clauses
• subcontractor approval and flow-down obligations
• confidentiality obligations
• moral rights consents where relevant for design and other copyright works

If those basics are missing, the external client contract may overpromise.

Ownership, assignment and licensing are not the same thing

A lot of disputes happen because people use these terms loosely. They are different.

• Ownership means the client owns the intellectual property rights in the relevant deliverables.
• Assignment means the creator or current owner transfers those rights to someone else.
• Licence means the owner keeps ownership but allows someone else to use the work on agreed terms.

For app agencies, a mixed model is often the most practical. The client may own bespoke project deliverables created specifically for them, while the agency keeps ownership of its pre-existing codebase, generic development tools, reusable modules and know-how, then licenses those elements to the client as needed.

That approach can work well, but only if the drafting is clear enough to identify the boundaries.

When This Issue Comes Up

This issue usually surfaces when the business needs to do something new with the app, not when everyone is still on good terms at the start of the project.

Ownership questions tend to become urgent at moments where the stakes are higher and timelines are tighter. That is why sorting it out before you spend money on setup and before you sign is much easier than trying to fix it later.

When a client wants to move to a new developer

A very common trigger is handover. The client wants another agency or an internal tech team to take over maintenance and asks for source code, design files, admin access, documentation and deployment credentials.

If the contract only gave a narrow licence, or if handover obligations were never defined, the outgoing agency may not be required to provide everything the client expected. Even where ownership is clear, practical control can still be a problem if repositories, cloud accounts or design tools remain under the agency’s name.

When an agency reuses parts of a previous build

Agencies often reuse existing code snippets, architecture patterns, templates or internal frameworks across clients. That is normal and commercially sensible.

The problem starts when the client believes the entire solution is unique and exclusively theirs. If you are the agency, you need to identify your background IP and reserve it expressly. If you are the client, you need to understand which parts are shared, which parts are bespoke, and whether the licence is broad enough for your future plans.

When the client is raising investment or selling the business

Investors and buyers usually ask who owns the software, designs and related intellectual property. They want to see that the business has rights to use, modify, commercialise and protect the core product.

If the answer is vague, due diligence can slow down or the deal value can be affected. A buyer may worry that the company does not control its main asset. An investor may ask for contract clean-up or contract review before funding is released.

When white label or reseller rights are involved

Some app projects are not just internal tools. The client may plan to on-sell the platform, licence it to customers, or create a SaaS product from the build.

That changes the ownership and licence discussion. A licence suitable for one business to operate an app internally may not be enough if the client wants to resell the product, create derivative works or expand internationally.

When branding, designs and trade marks overlap

App projects often blend software work with naming, logos, icons, layouts and other brand assets. Code ownership does not automatically resolve trade mark or brand ownership.

If an agency creates a new app name, logo or visual identity, the contract should deal with those rights separately. If the client intends to register a trade mark in New Zealand, they should make sure ownership of that branding work is properly addressed first.

When personal information is involved

Ownership of code is not the same as control of user data. App projects often involve personal information, customer accounts, analytics and support records.

Even if the client owns the app, the agreement should still address privacy responsibilities, data access, hosting arrangements, security steps and what happens to information at the end of the engagement. Under New Zealand privacy expectations, those operational details matter just as much as the IP clause, and a clear privacy policy may also be needed.

Practical Steps And Common Mistakes

The best protection is a written contract that separates bespoke deliverables, pre-existing materials, third party components and data, then states exactly who owns what and what each party can do with it.

Most ownership problems are not caused by unusual legal rules. They come from vague scopes, recycled contract templates and assumptions that everyone means the same thing when they say “the client owns the app”.

1. Define the deliverables properly

Do not rely on broad labels like “app”, “platform” or “design package”. Break the work into identifiable categories.

Your agreement should describe, where relevant:

• frontend code
• backend code
• source files and repositories
• design files and prototypes
• copy and content
• documentation
• configuration files
• deployment materials
• training materials
• access credentials and account ownership

The more specific the list, the less room there is for argument later.

2. Separate background IP from project IP

This is one of the biggest drafting points for app agencies. Background IP means the materials a party already owned before the project, or develops independently of it, such as libraries, methods, templates, frameworks and generic tools.

If you are the agency, reserve ownership of your background IP clearly. If you are the client, make sure you receive a licence broad enough to use the finished product as intended, including future maintenance, bug fixing and upgrades where relevant.

Good drafting usually distinguishes between:

• client materials supplied to the agency
• agency pre-existing materials
• third party software and open source components
• new bespoke deliverables created for the project

3. Say when ownership transfers

Ownership should not be left floating. The contract should state whether assignment happens on creation, on full payment, or when a separate written assignment is signed.

Many agencies prefer transfer on full payment. That is commercially understandable, but the clause needs to say so clearly. Clients should also check what rights they have to use incomplete work if a project ends early after part payment.

4. Cover licences with enough detail

A licence clause should answer more than just “yes” or “no”. It should explain the scope of use.

For example, think about:

• whether the licence is exclusive or non-exclusive
• whether it is perpetual or limited in time
• whether it can be sublicensed
• whether it covers modification and further development
• whether it allows commercial resale or white labelling
• whether it ends if fees are unpaid or the contract is terminated

If a client plans to scale the app into a core revenue product, a narrow operational licence may not be enough.

5. Check open source and third party terms

Not all code in a project will be owned by either party. Many builds include open source software, SDKs, plugins, fonts, stock assets, cloud integrations and third party APIs.

Those components come with their own licence terms, and sometimes usage restrictions. A contract should explain who is responsible for selecting, approving and complying with those terms. It should also make clear that neither party can promise ownership of third party materials they do not control.

6. Deal with moral rights and attribution issues

Designers and other creators may have moral rights connected to certain works. In practice, commercial contracts often include consents so the client can adapt, publish or use the work without later objections about treatment or attribution.

This is especially relevant where visual design work, illustrations or branded creative assets are part of the app build.

7. Align the client contract with worker contracts

An agency cannot safely promise ownership to a client if its own team agreements do not support that promise. This is a common internal gap for growing agencies.

Before you sign a major client deal, check that your employment contracts and contractor agreements line up with your external terms. If they do not, fix that first.

8. Include handover and exit terms

Ownership without handover can still leave a client stuck. The agreement should address what the agency must provide at the end of the engagement, in what format, and within what timeframe.

That may include:

• source code export
• repository transfer
• design files
• technical documentation
• credentials and access details
• database exports
• deployment instructions
• reasonable transition support

If you are the agency, define what is included in the fee and what is extra. If you are the client, do not leave transition assistance to goodwill alone.

Common mistakes founders and agencies make

These are the patterns that cause the most trouble:

• assuming payment automatically equals ownership
• using a short proposal with no intellectual property clause
• failing to identify pre-existing agency tools and reusable code
• forgetting to get contractor assignments
• treating branding, code and data as if they are all the same asset
• ignoring third party licence terms
• not documenting who controls hosting, domains, app store accounts or repositories
• agreeing to “client owns everything” without protecting the agency’s general know-how and templates

Each of those mistakes can be fixed at the contract stage. They are much harder to resolve once the product is live and the parties have fallen out.

A practical example

Imagine a Wellington agency builds a booking app for a fitness startup. The agency uses its own reusable admin dashboard framework, integrates a third party payment gateway, creates custom UX designs, and writes bespoke code for membership logic.

A clear contract might say the startup owns the bespoke membership logic, custom designs and final branded content once all fees are paid. The agency keeps ownership of its pre-existing dashboard framework and development tools, but licenses them to the startup on a perpetual basis so the app can operate and be maintained. Third party services remain subject to their own licence terms, and the agency must provide repository access, design files and transition support on exit.

That structure is usually more realistic than pretending every component is wholly new and wholly transferable.

FAQs

Does the client automatically own software created for them?

No. In many cases, ownership depends on the contract and any assignment wording. Paying for development work does not always transfer intellectual property by itself.

Can an app development agency keep its reusable code and frameworks?

Yes, if the contract reserves that background intellectual property to the agency and gives the client an appropriate licence to use it as part of the finished product.

What if freelancers or subcontractors worked on the app?

The agency should have written agreements that assign intellectual property from those contributors to the agency, or otherwise allow the agency to pass the promised rights to the client. Without that, ownership can be uncertain.

Who owns the designs, logo or branding created during the project?

That depends on the contract. Code, UI designs, logos and trade mark-related assets should be dealt with specifically, because they may involve different rights and future uses.

Is owning the app the same as owning the user data?

No. Intellectual property ownership and control of data are different issues. Your agreement should separately cover privacy, access, hosting, security and data return or deletion at the end of the project.

Key Takeaways

• In New Zealand app development projects, ownership of code, designs and related deliverables usually depends on the contract, not assumptions.
• Clients should confirm exactly what they will own, what is only licensed, and when any transfer takes effect.
• Agencies should clearly reserve pre-existing tools, frameworks and reusable materials while making sure client rights still match the commercial deal.
• Employee, contractor and subcontractor agreements need to support whatever the agency promises to the client.
• Third party software, open source components, branding assets, repositories, hosting access and data handling should all be addressed separately.
• Clear handover and exit terms matter just as much as ownership clauses, especially if the client may change developers later.

If your business is dealing with who owns creative work app development agency and wants help with development contracts, intellectual property assignments, contractor agreements, privacy and handover terms, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.