When One App Copies Another: Feature Copying, IP Risks and Contracts

Your competitor launches a feature that looks very familiar. Or you hire a developer and realise the product they are building is very close to someone else’s app. This is where founders often get caught. They assume an idea is protected when it is not, they rely on verbal promises about ownership, or they copy interface elements without checking whether copyright, trade mark, confidentiality or contract terms are in play.

When one app copies another, the legal answer is rarely as simple as “they copied us, so we can stop them”. In New Zealand, whether you have a real claim often depends on what was copied, how it was accessed, what your contracts say, and whether you protected the right parts of your product in the first place.

This guide explains what feature copying means for New Zealand businesses, where intellectual property risks usually sit, what to check before you sign a development, partnership or procurement agreement, and the common mistakes founders make before they spend money on setup, branding or product changes.

Overview

App copying disputes usually turn on details, not headlines. The law may protect code, designs, branding, confidential information and some creative content, but it does not automatically give one business a monopoly over a broad app concept or common functionality.

A practical response often combines intellectual property analysis with contract review, evidence gathering and a realistic commercial plan.

• Work out exactly what has been copied, code, visual design, branding, data structure, content, workflows or only a general idea.
• Check which rights may apply, including copyright, trade marks, confidential information and any contractual ownership clauses.
• Review developer, contractor, co-founder, reseller and platform agreements before you rely on assumptions about ownership or exclusivity.
• Gather evidence early, including dated screenshots, design files, source code records, access logs and written communications.
• Assess whether your own product also borrows from third party material, open source code, templates or white label arrangements.
• Consider the commercial outcome you actually want, such as changes to the app, rebranding, licence terms, settlement or a clean assignment of rights.

What When One App Copies Another Means For New Zealand Businesses

When one app copies another, the main legal question is not whether the products feel similar. The real question is whether a legally protected right has been used without permission, or whether a contract or confidentiality obligation has been breached.

Ideas are not protected in the same way as expression

New Zealand businesses are often surprised by this point. A general app idea, such as matching service providers with customers, booking appointments, tracking deliveries or sharing short videos, is usually not protected just because you thought of it first.

What can be protected is the specific expression of that idea. Depending on the facts, that may include:

• source code and object code
• original screen designs, graphics and written content
• logos, app names and brand identifiers
• customer databases and proprietary datasets, where confidentiality and access controls support protection
• technical documentation, wireframes and internal product plans

This distinction matters before you accuse another business of copying. Two founders can independently build similar features without one infringing the other’s rights.

Copyright may protect code and content, but not every feature

Copyright is often the first issue raised when one app copies another. In practice, copyright can protect original code, text, images, audio, graphics and some interface elements. It does not usually protect a broad function, method or business logic on its own.

For example, a competitor may be free to offer in-app booking or a swipe-based interface if they created their own implementation. But if they copied substantial parts of your code, duplicated your onboarding text, lifted your custom illustrations, or reused your exact screen layouts in a way that reproduces original expression, the risk increases.

This is why evidence matters. Similar user outcomes do not automatically prove copying. Before you send a demand letter or threaten action, you need to compare the protected material with what has actually been reproduced.

Trade marks matter when branding starts to look familiar

Sometimes the real issue is not feature copying at all. It is brand confusion.

If another app uses a name, logo, slogan or store listing that is too close to yours, your strongest argument may sit in trade mark law or misleading conduct concerns rather than code ownership. This becomes especially relevant before you invest in branding, register a domain or print packaging for any connected product offering.

Trade mark protection can be particularly valuable for:

• app names
• company names used in market
• logos and visual identifiers
• taglines closely tied to the service

Registration does not solve every dispute, but it can put you in a far better position if a competitor adopts something deceptively similar.

Confidential information is often the missing piece

Many app disputes start long before launch. A founder shares product plans with a freelancer, software studio, adviser, marketplace partner or potential investor. Later, a suspiciously similar feature appears elsewhere.

If the copied material was confidential and disclosed in limited circumstances, your rights may depend heavily on confidentiality obligations rather than pure intellectual property law. This is where founders often get caught by informal conversations and patchy records.

Useful factors include:

• whether the information was clearly confidential
• whether access was limited on a need-to-know basis
• whether there was a non-disclosure agreement or confidentiality clause
• whether internal files and repositories were access-controlled
• whether the recipient was allowed to reuse the material for other clients

If your product strategy, wireframes or technical architecture were shared freely without clear restrictions, it may be harder to argue that another party misused confidential information.

Developer ownership is a frequent source of trouble

Businesses often assume that if they paid for the app, they own all the underlying rights. That is not always true.

If an external developer, agency or contractor created the code or design, the contract should clearly state who owns new intellectual property, what pre-existing tools remain with the developer, and what licence rights the customer receives. Without clear contract drafting, you may discover that the developer reused components across multiple clients, retained key rights, or cannot validly assign parts built on third party tools.

Before you rely on a verbal promise, check whether your contract covers:

• assignment of newly created intellectual property
• developer rights in pre-existing code libraries and frameworks
• use of open source software and applicable licence terms
• rights to modify, maintain and transfer the app to another provider
• restrictions on reusing your custom work for other customers

These points matter whether you are the customer commissioning the app or the studio building it.

Legal Issues To Check Before You Sign

Before you sign a development or commercial agreement connected to an app, the main job is to pin down ownership, usage rights, confidentiality and responsibility if copying allegations arise later.

Who owns what, and when?

The contract should separate pre-existing intellectual property from new work created under the project. That sounds technical, but it is central to avoiding disputes.

For example, a software studio may bring its own libraries, templates and tools. Your business may bring its brand assets, workflows and data. The project may then produce new code, visual assets and documentation. Each category should be addressed expressly.

Key clauses often cover:

• ownership of background intellectual property each party already had before the project
• assignment or licensing of project-specific deliverables
• timing of ownership transfer, such as on creation, on payment or on acceptance
• moral rights consents where relevant for creative works
• rights to future enhancements, updates and derivative works

If you leave this vague, the dispute can become expensive very quickly.

Are you only getting a licence?

Many businesses discover too late that they do not own the app at all. They only have a limited licence to use it.

A licence may still be perfectly workable, but you need to know its boundaries before you sign. For instance, can you sublicence the platform to customers, migrate it to another host, engage a new developer, or continue using it if the relationship ends?

Before you accept the provider’s standard terms, look closely at:

• whether the licence is exclusive or non-exclusive
• whether it is revocable
• which territories, users and business units can use the app
• whether source code access is included
• what happens on termination, insolvency or non-payment

If your whole business depends on the app, these terms are not boilerplate.

What if a third party says the app copies them?

Your contract should say who carries the risk if someone alleges infringement. Without this, each party may point at the other when a complaint arrives.

An agreement may deal with:

• warranties that supplied material does not knowingly infringe third party rights
• indemnities for losses arising from infringement claims
• processes for notifying, defending and settling claims
• obligations to modify, replace or remove infringing content or code
• limits on liability and any carve-outs for intellectual property breaches

Founders often focus on price and delivery dates, then miss this section entirely. That is risky if your supplier is using subcontractors or offshore development teams.

How is confidential information handled?

Confidentiality clauses should do more than ban disclosure in general terms. They should define the information covered, the permitted use, who can access it, and what must happen when the relationship ends.

This is especially important where you are sharing product roadmaps, customer lists, growth metrics, pricing logic, algorithms, training data or unpublished features. If a later dispute arises, a strong paper trail can make a major difference.

Practical contract points include:

• labelling and treatment of confidential information
• security standards and repository access rules
• restrictions on copying, reverse engineering and competitive use
• return or deletion obligations on exit
• survival of confidentiality duties after termination

Are you allowed to use all third party materials in the build?

App products often depend on more than your own code. There may be APIs, open source components, templates, stock imagery, maps, fonts, analytics tools and white label modules in the stack.

Before you sign, ask for a clear schedule of third party materials and the terms attached to them. The issue is not only infringement. It is also whether those third party rights limit your commercial model, your exclusivity, your resale rights or your ability to exit the relationship.

If personal information is involved, privacy obligations also need attention. If the app collects customer or user data, your documents and operational practices should reflect New Zealand privacy requirements, including transparency in your privacy notice about collection and use.

Common Mistakes With When One App Copies Another

The most common mistake is assuming that “copying” is obvious. In legal terms, founders need to identify the exact material, right and obligation in issue before they spend money, threaten action or rebuild the product.

Confusing market similarity with legal infringement

Plenty of apps in the same category look and feel alike because users expect familiar patterns. Booking flows, menus, payment screens and profile pages often follow standard conventions. Similarity alone is not enough.

If your concern is real, compare the specific original parts of your product with the other app. Look for evidence of access, replication and substantial similarity in protected material.

Failing to secure rights from developers and designers

This is one of the biggest commercial traps. A startup commissions an MVP, pays the invoice, then assumes ownership is settled. Later, the relationship breaks down and the business learns it cannot freely reuse or modify the work.

Before you spend money on setup or a major rebuild, make sure your development agreements, contractor terms and founder arrangements clearly address intellectual property ownership and permitted reuse.

Using templates, code or branding without checking licence terms

Some businesses worry about others copying them while overlooking their own upstream risk. If your app uses code snippets from online forums, design kits, stock elements, white label solutions or open source packages, your rights may be narrower than you think.

Check whether you can use those materials commercially, modify them, keep your source code closed, or stop others from using the same base component. If not, your ability to complain about a similar product may be limited.

Sharing product plans too freely

Early-stage businesses often pitch widely and document poorly. They send wireframes to multiple agencies, discuss strategy in open channels, and never require confidentiality undertakings.

That can weaken your position if a similar feature later appears elsewhere. Before you rely on a verbal promise, put confidentiality terms in writing and limit access to people who genuinely need the information.

Waiting too long to collect evidence

If another app has copied material from you, evidence can disappear quickly. Screens change, repositories update and staff move on.

Save dated records as soon as concerns arise, such as:

• screenshots and screen recordings
• app store descriptions and release notes
• source code commits and repository logs
• design files and creation dates
• emails, messages and proposal documents

Do this before you sign a settlement, switch developers or make public accusations.

Sending aggressive complaints too early

A strong reaction can feel satisfying, but it can also backfire. If your claim is overstated, the other side may push back hard, raise defamation concerns, or force a deeper review of your own rights chain.

A measured first step is usually better. Confirm what rights you hold, what was copied, what the contract says, and what commercial outcome you want. In some cases, a practical negotiation about changes, attribution, transition or licensing is more useful than a fight over broad allegations.

FAQs

Can you protect an app idea in New Zealand?

Usually not by itself. The law is more likely to protect the specific expression of the idea, such as code, designs, written content, branding and confidential product materials.

If a competitor copies our features, can we stop them?

Maybe, but it depends on what they copied. If they only adopted a similar concept or common functionality, you may have limited options. If they copied code, creative assets, branding or confidential information, your position may be much stronger.

Do we own the app if we paid a developer to build it?

Not automatically. Ownership depends on the contract, the parties involved, and whether third party materials were used. Before you sign, make sure the agreement clearly covers assignment, licensing and reuse rights.

What should we do first if we think another app copied us?

Identify exactly what was copied, preserve evidence, review your contracts and confirm what rights you actually own. That gives you a clearer basis for any commercial or legal response.

Can confidentiality clauses help if someone uses our product plans?

Yes, often significantly. If your plans, wireframes, data or technical documents were shared in confidence, a confidentiality clause can be an important part of your position, especially where pure copyright arguments are uncertain.

Key Takeaways

• When one app copies another, similarity alone is not enough. You need to identify the protected material or contractual obligation that was actually used without permission.
• Copyright may protect code, content and some original design elements, but broad features and common functionality are not automatically exclusive.
• Trade marks, confidentiality and carefully drafted contracts are often just as important as copyright in app copying disputes.
• Developer and contractor agreements should clearly address ownership, licensing, third party components, confidentiality and infringement risk allocation before you sign.
• Evidence should be preserved early, including screenshots, design files, code records and written communications.
• A practical commercial strategy matters. In some cases the right outcome is a change, licence, assignment, rebrand or negotiated settlement rather than an immediate dispute.

If you want help with developer contracts, intellectual property ownership, confidentiality terms, trade mark issues, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.