How To Own The IP In Your Freelance Developer's Work

Mia runs a Wellington healthtech startup. She pays a freelance developer $12,000 to build her MVP, gets the app working, and starts speaking with investors. Then an investor asks a simple question: can you prove the company owns the code?

Mia has invoices, Slack messages and access to the GitHub repo. But the developer says some of the code is his reusable framework, some of it came from open-source libraries, and he never signed anything transferring IP to the company.

This is a very common moment for startups. Paying an invoice can feel like the final step, but software IP ownership in New Zealand can be more layered than that. The good news is that you can usually sort this out with clear documents and a practical process.

Does Paying A Freelance Developer Mean You Own The Code?

Not always. In New Zealand, paying a developer can matter a lot, but it doesn't always give you the clean, investor-ready ownership position you need.

Under the Copyright Act 1994, computer programs are protected as literary works. Copyright generally protects the code itself, not the broad idea for your app, platform or feature.

New Zealand has a useful rule for some commissioned works. If you commission and pay, or agree to pay, for a computer program, your business may be the first owner of copyright in that commissioned program, unless your contract says something different.

That sounds reassuring, but there are still gaps. You can run into problems if:

• there's no clear written scope showing exactly what was commissioned
• the developer used pre-existing code, templates, scripts or frameworks they already owned
• the developer is overseas and another country's law is involved
• the contract says the developer keeps ownership until full payment, or keeps ownership entirely
• the work includes UI designs, graphics, documentation, databases, trade marks or product names, not just code
• you need to show investors, grant funders or commercial partners a clean chain of title

So, while paying for a commissioned computer program may help under New Zealand copyright law, it isn't a substitute for a proper written IP clause. A signed deed of assignment is much easier to show to an investor than a folder of invoices and messages.

What Should A Software IP Assignment Clause Say?

A software IP assignment clause should clearly transfer the relevant IP in the developer's work to your business, and explain when that transfer happens.

For a startup, the clause should be practical, not just legal-sounding. You want it to match how the work is actually being created, sprint by sprint, commit by commit.

A strong clause usually covers:

• Who gets the IP: the company or business entity, not just you personally as a founder. If you have a company, use the correct Companies Office name, NZBN details and company constitution details where relevant.
• What is being assigned:source code, object code, scripts, architecture, databases, API documentation, technical notes, UI files, designs, copy, test materials and other deliverables.
• When ownership transfers: for example, on creation, on delivery, or on payment for the relevant milestone. The right timing depends on your payment structure and bargaining position.
• Where it applies: worldwide, because software is rarely used only in New Zealand.
• Future rights: the developer agrees to sign further documents if needed to confirm or register ownership later.
• Carve-outs: anything the developer owned before the project stays with them, but your business gets the licence it needs to use the finished product.

Be careful with vague wording like the client owns the project. That might not clearly deal with source code, reusable tools, documentation, design files, future modifications or background IP.

If your app name, logo or product brand is part of the project, copyright assignment won't be the whole answer. You may also need trade mark protection through IPONZ. Registering a company name with the Companies Office or having an NZBN doesn't give you trade mark ownership.

What About Background Code, Open-Source Tools And Third-Party Libraries?

Your contract should deal with these clearly, because most modern software isn't built from a blank page.

Freelance developers often use code they have built before. They may also use frameworks, packages, AI-assisted tools, APIs, stock icons, fonts and open-source libraries. That isn't automatically a problem. The issue is whether your business has the rights it needs to use, modify, commercialise and scale the product.

Your developer contract should require the developer to:

• tell you what pre-existing code or tools they're using
• confirm they have the right to include those materials in your product
• give your business a broad licence to use any background code that stays owned by the developer
• get your written approval before using open-source components with restrictive terms
• keep a list of open-source packages, licences and versions
• avoid code that would force you to release your proprietary source code, unless you expressly agree

For example, Hemi pays $18,000 for a booking platform for fitness studios. The developer uses a date-picker library under a permissive MIT-style licence, which is usually manageable if the licence terms are followed. But the developer also uses an analytics module under a stronger copyleft licence without telling Hemi.

When Hemi later prepares for a partner launch, his technical adviser flags that the analytics module may require extra disclosure or changes. Replacing it costs $6,500 and pushes the demo back by three weeks. That cost could have been avoided with an open-source approval process at the start.

This is why your contract shouldn't just say the developer assigns all IP. It also needs a sensible plan for code the developer can't assign because they don't own it.

Do Moral Rights Matter For App Developers In NZ?

Sometimes, but moral rights usually aren't the main issue for raw software code in New Zealand.

Under the Copyright Act 1994, creators can have moral rights, such as rights connected with being identified as the author and objecting to derogatory treatment of their work. The rules are more limited for computer programs, but they can still matter for product assets around the software.

For example, moral rights may be relevant to:

• UI artwork and illustrations
• icons, animations and product graphics
• marketing copy or in-app written content
• training videos, explainer videos or audio
• technical diagrams and product documentation

A moral rights clause usually says the developer and any subcontractors consent to your business editing, adapting, translating, combining and commercialising the deliverables without needing further approval. Where the law allows, it may also include a written waiver of moral rights.

This matters because software changes constantly. You may redesign screens, remove features, combine the product with another platform, white-label it, or ask another developer to refactor the code later. You don't want a contractor saying your normal product changes damage their reputation or require their name to be displayed in a particular way.

If your developer works with designers, animators, copywriters or overseas subcontractors, make sure the moral rights consent flows down to them too. Your contract with one developer won't automatically bind people they brought into the project unless the contract is drafted to cover that.

How Do You Keep Your Product Idea And Code Confidential?

You should put confidentiality protections in place before you give a developer access to your idea, codebase, customer data or systems.

Confidentiality isn't just about stopping someone from copying your product. It's also about controlling how sensitive business information is handled while the product is being built.

Your confidentiality clause should cover:

• product ideas, feature plans, roadmaps and commercial strategies
• source code, repository access, credentials and technical architecture
• customer lists, usage data, pricing and supplier information
• security processes, API keys and system passwords
• investor materials, pitch decks and financial information
• whether the developer can mention your project in a portfolio or case study

If the developer will access personal information, you also need to think about the Privacy Act 2020. This can come up quickly if you're using real customer data for testing, analytics, support or onboarding. Your contract should say how personal information can be used, stored, protected, returned or deleted.

Good contract wording helps, but practical controls matter too. You can reduce risk by:

• using separate accounts for each developer
• turning on multi-factor authentication
• giving access only to the systems they need
• keeping audit logs for repositories and cloud platforms
• removing access promptly when the project ends
• using dummy or de-identified data where possible

Trade secrets are much easier to protect when your behaviour matches your contract. If everything is shared freely in personal inboxes and old contractors keep admin access, it's harder to show you treated the information as confidential.

What Should Be In A Freelance Developer Contract?

Your freelance developer contract should tie the technical work, payment, IP ownership and confidentiality obligations together in one clear document.

Templates can be a helpful starting point, but software projects have details that generic documents often miss. Before you use a contract, a lawyer or experienced legal team should tailor it to your product, team structure and commercial plan.

A useful outline looks like this:

1. Parties: name your company or business correctly, including NZBN details where available.
2. Scope Of Work: describe the product, sprint process, deliverables, repositories, environments and acceptance criteria.
3. Fees And Milestones: set out fixed fees, hourly rates, payment dates, invoice requirements and what happens if scope changes.
4. IP Assignment: state what IP is assigned to your business and when ownership transfers.
5. Background IP Licence: list any pre-existing code or tools and give your business the rights it needs to use them.
6. Open-Source And Third-Party Materials: require disclosure, approval and compliance with licence terms.
7. Moral Rights: include consents and waivers where legally available, especially for non-code assets.
8. Confidentiality And Privacy: protect business information, customer data, credentials and product plans.
9. Warranties: require the developer to confirm the work is original or properly licensed, and doesn't knowingly infringe someone else's rights.
10. Security And Access: set rules for accounts, devices, passwords, repositories and offboarding.
11. Contractor Status: confirm the developer is an independent contractor and explain responsibility for tax, tools and work methods.
12. Support And Handover: cover bug fixes, documentation, deployment notes and transition to your internal team.

Contractor status deserves care. From 2026, changes under the Employment Relations Amendment Act 2026 introduced a contractor gateway test for some arrangements. Broadly, this looks at things like having a written contractor agreement, whether the person can work for others, their freedom around accepting work or availability, and what happens if they decline extra work.

If your working relationship doesn't match the paperwork, there may still be employment law risk under the Employment Relations Act 2000, and employee entitlements can involve the Holidays Act 2003. Classification also affects IP analysis, so it's worth getting the setup right from day one.

What Should You Do If You've Already Hired The Developer?

Start by getting the paper trail clear, then fill the gaps with a confirmatory IP assignment where you can.

If the developer is still friendly and the project is ongoing, it's often much easier to tidy this up now than later. Don't wait until an investor, grant provider or enterprise customer asks for proof.

Work through these steps:

1. Collect the documents: gather invoices, proposals, statements of work, emails, messages, repository records and payment receipts.
2. Map the deliverables: list what was created, including source code, designs, documentation, scripts, databases and configuration files.
3. Identify third-party materials: ask for a list of open-source packages, APIs, stock assets, fonts and pre-existing code.
4. Check the repo: review who contributed code, when it was committed and whether any subcontractors were involved.
5. Ask for a confirmatory assignment: have the developer sign a document confirming the IP position and any licences your business needs.
6. Lock down access: make sure accounts, credentials and admin permissions are current and controlled by your business.
7. Update your process: use a proper developer contract for future sprints, contractors and contributors.

If the developer pushes back, avoid making assumptions about who owns what. The answer can depend on the wording of your messages, what was commissioned, where the developer is based, what has been paid, and whether background IP or open-source components are involved.

For investor readiness, keep your IP records, shareholders agreement and company records in one place. A simple folder with signed contracts, assignments, open-source registers and brand registrations can save you a lot of stress during fundraising or partnership conversations.

Key Takeaways

• Paying a freelance developer may help under New Zealand copyright law, but it isn't always enough to prove clean ownership of your software assets.
• A written IP assignment should cover source code, product assets, future rights, background IP, open-source materials and handover obligations.
• Open-source software isn't off-limits, but you need disclosure, approval and licence compliance so your product can scale safely.
• Moral rights clauses can matter for UI artwork, documentation, marketing assets and other creative work around the code.
• Confidentiality, Privacy Act 2020 protections and practical access controls should be in place before developers touch sensitive systems or data.
• If you've already started without a contract, collect the paper trail and consider a confirmatory assignment as soon as possible.

If you'd like help with your freelance developer contracts, software IP assignments, confidentiality terms or open-source clauses, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.