Which App Features Should You Copy vs Create Fresh?

A pre-launch founder in the football industry came to us with a colour-coded spreadsheet. Every competitor product mapped out, feature by feature, with clear annotations about what they planned to absorb into their own app. They were visibly pleased with themselves, and you could understand why, it felt like thorough preparation. The spreadsheet was detailed, confident, and entirely untested against a single real user. When we started asking why someone would choose an all-in-one product over the specialised apps they already used, the energy in the room changed. The founder became deflated. That reaction, more than anything the spreadsheet contained, told us where the real problem was.

The question is not what your competitors built, but what your users actually need that nobody else is giving them.

The question of what to copy and what to create from scratch sits underneath almost every product decision. Get it wrong in one direction and you spend months building something users already have and prefer elsewhere. Get it wrong in the other and you spend the same months reinventing a login screen when you could have been solving a problem nobody else has touched. The decision is a question of where your product's energy belongs, and answering it badly is one of the most common ways good ideas become forgettable apps.

This article sets out how to make that call deliberately, using the right criteria, without a spreadsheet that only tells you what already exists.

Why Feature Parity Is Not a Strategy

Matching a competitor feature for feature feels safe. It gives you a checklist, a clear scope, and something to show in a pitch deck. The problem is that users do not choose products by checklist. They choose based on how a product makes them feel, whether they trust it, and whether it fits the specific situation they are in. A feature that works beautifully inside one product does not automatically carry that effect when it is lifted out and installed somewhere else.

Research on this point is substantial. Having equivalent or even superior features to a competitor does not guarantee adoption. What matters is whether users' emotions, their particular use cases, and the context in which they are operating are genuinely understood. A checkout flow that delights customers in a fashion retail app and a checkout flow that delights customers booking a healthcare appointment are not the same interaction, even if they share every UI component. The label on the button is the same. The psychological state of the person pressing it is completely different.

Feature parity also creates a specific trap for teams. Once you frame the work as "matching what competitor X has", the conversation about what users actually need stops. You are no longer designing for a person in a situation. You are designing for a spreadsheet cell. The football founder's colour-coded grid was a vivid version of this: every cell told them what existed in the market, and none of it told them whether any of those features solved a problem their prospective users were genuinely experiencing.

The Core Decision: Competitive Advantage vs. Functional Necessity

Every feature in your product falls into one of two categories. Either it is functional infrastructure, the kind of thing users expect as a baseline and will notice only by its absence, or it is a point of difference that shapes why someone would choose your product over another. The decision to copy or create is really a question of which category you are in.

Functional infrastructure rarely benefits from reinvention. Password reset flows, notification preferences, basic account management: these exist in a form that users already understand, and spending creative energy redesigning them diverts that energy from the places where your product can actually be distinctive. Staying within familiar interaction patterns is sound practice here, because users have built up mental models from years of using other products, and working with those models reduces friction without adding any value to break them.

Differentiation, by contrast, is the territory where copying is most dangerous. If your product's value lies in how it handles a specific user need differently from everyone else, importing a competitor's solution to that same need produces a product that does nothing better. The places where you create from scratch should be the places your users feel most strongly, where the existing solutions are failing them, or where your product's particular context demands a genuinely different response.

Criteria for Copying: When Established Patterns Are the Right Answer

Copying is the right call when a pattern already carries the cognitive work. Users arrive at your product with expectations built from everything they have used before. A hamburger menu, a pull-to-refresh gesture, a progress bar through a multi-step form, these interact with existing mental models rather than asking users to build new ones. Deviating from them without a strong reason is friction.

There are three situations where adopting an established pattern is clearly the right answer. First, the feature is infrastructure, the baseline your product is built on rather than the ground where it competes. Second, your users are already familiar with the pattern from a product they trust, so it carries positive associations into your experience. Third, the cost of learning a new interaction would slow users down at a point in the journey where speed and confidence matter.

Copying earns its place when the pattern reduces cognitive load without giving away any competitive ground.

We worked on a fitness community app where the team initially wanted a novel onboarding sequence to signal that the product was different. The problem was that users arriving at the app were anxious about whether it would be worth committing to. A familiar, low-friction onboarding reduced that anxiety and got users to the parts of the product that were genuinely distinctive far more quickly. The originality belonged inside the core experience, not at the gate to it.

Before investing in a novel interaction, ask whether the version that already exists in users' mental models is actively failing them. If not, the established pattern is probably the right call.

Criteria for Creating: When Originality Actually Changes Behaviour

Creating from scratch earns its place when the existing patterns would produce an outcome that contradicts your product's purpose. We worked on a football social app specifically designed to reduce online hate. The standard social engagement model, likes, dislikes, visible reaction counts, would have reproduced the exact dynamics the app was trying to remove. So we replaced it. The app used a favourites mechanic instead, with limited comment functionality and no ability to publicly dislike content. The design challenge was keeping the product feeling like a genuine community rather than a passive feed, while removing the social pressure that visible approval metrics create.

That decision to create was driven by a specific, measurable conflict between what the established pattern does and what this product needed to do. The same logic applies anywhere a copied feature would undermine the product's core purpose rather than support it.

A second case for original design is when users are experiencing a real failure in their current process that existing products have not addressed. If there is a genuine gap, and your original feature fills it in a way users recognise as better, the investment in creation is justified. The test is whether the original feature changes behaviour in a meaningful way: do users do something they could not or would not do before? If the answer is yes, the feature has earned its place. If users interact with it once and revert to their previous approach, it has not.

Ask whether the standard pattern would actively work against your product's purpose. If yes, that is the signal to design something new. If not, check whether the effort of creation could be spent somewhere it genuinely shifts behaviour.

The Competitor Spreadsheet Trap

The football founder's colour-coded spreadsheet is not unusual. Competitive feature mapping is one of the most common first moves in product development, and it is easy to understand why. It is concrete, it is fast, and it produces something that looks like a strategy without requiring any conversations with actual users. As Simon has noted, it also gives founders immediate validation of their existing opinions, because without user research, nothing can contradict what is already in the spreadsheet.

The deeper problem is what the spreadsheet cannot tell you. It shows you what competitors built. It does not show you whether users are satisfied with those features, whether the features are driving retention, or whether they are quietly creating the friction that your product could resolve. A feature appearing in three competitor products does not mean it is working in any of them. It sometimes means three teams copied the same original without ever testing whether it was worth keeping.

According to Pendo, public cloud software companies collectively squander up to $29.5 billion in R&D annually on features that go unused after shipping. That figure does not surprise us. A significant portion of that waste traces back to feature decisions made from competitive observation rather than from understanding what users actually do.

The spreadsheet has a place, it is a useful starting map of the territory. The error is treating it as a specification.

Context Is Not Transferable

One of the most common mistakes we see in product briefs is the assumption that a feature that works in one product will work in another because both products operate in the same general category. Taking a feature from a product that does something similar to yours in a different scenario and implementing it in your own product is not necessarily going to make it work. The emotional context a user is in when they open a travel booking app is different from the one they are in when they open a healthcare self-management app, even if both products contain a calendar, a notification system, and a personalised dashboard.

When people describe a competitor's product as feeling intuitive, they are often also describing something broader: they understand what the product is for, and that understanding bleeds out into how individual features feel. A feature that feels right inside a product the user already trusts and understands can feel confusing or arbitrary when lifted into a product where that context does not exist yet. The feature did not change. The surrounding meaning did.

We encountered this clearly on a project involving location sharing in a running community app. Precise location data, a feature that works straightforwardly in some fitness contexts, created genuine anxiety for users thinking about meeting strangers for a run. The solution was to display only a vague area rather than a precise pin, which preserved personal safety while still giving users enough information to judge whether someone was nearby and worth meeting. The feature category was the same as dozens of other apps. The specific implementation had to be different, because the emotional stakes were different.

How to Adapt Rather Than Copy Wholesale

Between pure copying and building from scratch, there is a third approach that is often the right one: adapting an established pattern to fit your specific context. This means taking the structural logic of a proven feature and reshaping it around your users' particular situation, rather than either transplanting it unchanged or designing from a blank page.

Adaptation starts with identifying what the original feature is actually doing for users, not what it looks like. Netflix's "Are you still watching?" prompt, for example, is a deliberate interruption that restores the user's sense of agency at a moment when passive consumption has taken over. The structural logic, a periodic pause that gives users a conscious decision point, is transferable. The execution needs to fit the product it lands in.

A useful process for adaptation works in four steps.

1. Identify what problem the original feature is solving for its users.
2. Map whether your users face the same problem or a different version of it.
3. Determine what emotional state your users are in at the moment the feature fires.
4. Design the feature for that emotional state, not for the original one.

This approach preserves the cognitive efficiency of working within familiar patterns while making the feature appropriate for a genuinely different context. It is slower than copying and faster than building from scratch, and it produces something the spreadsheet never could.

When reviewing a competitor feature you want to adapt, write down in one sentence what problem it solves. Then write down whether your users have that exact problem. If the problem statement changes, the feature needs to change with it.

Where to Spend Your Differentiation Budget

Differentiation has a cost. Original feature design takes longer, carries more risk, and requires more research than adopting a pattern that already exists. This means the question of where to create rather than copy is also a question of where to spend a limited budget of time, attention, and development capacity. Spending that budget evenly across all parts of the product is a reliable way to produce something distinctive nowhere.

The places worth spending differentiation budget are the moments that define your product's relationship with its users. These are typically the moments of first value, when a user understands for the first time that the product does something genuinely useful, and the moments of highest emotional charge, where the product and the user's situation intersect most directly.

On the dating app we worked on, significant effort went into onboarding verification, which was the right call for building trust early. What became clear later was that discovery had not been applied equally to messaging. The messaging feature was built generically, which allowed the very behaviour, fake, automated messages, that the onboarding was designed to prevent. Product coherence requires discovery across all interconnected parts. Skipping it in one area, even while investing heavily in another, creates internal contradictions that users feel even when they cannot name them.

Differentiation budget belongs in the parts of the product that are interconnected with your core promise. Infrastructure can be adopted from established patterns. The moments that define what your product is for deserve the investment in original thinking.

Testing Whether Your Original Features Are Earning Their Place

Building an original feature is the beginning of a question. The question is whether the feature is doing something for users or whether it is there because it seemed like a good idea during a workshop. Teams rarely ask this question directly enough, and the features that survive unchallenged are often the ones most in need of examination.

One approach we use is a version of the removal test. Ask what would happen to the product if a specific feature were turned off for a subset of users. If the team's instinctive response is that they would never do that, that reaction itself is diagnostic. It means the feature is likely retained to serve platform metrics rather than user needs, and that the team implicitly knows this. An original feature that cannot be turned off without anxiety is either genuinely valuable or defensively protected, and the only way to know which is to test it.

There are three signals that an original feature is earning its place.

• Users return to it without being prompted.
• Removing it for a test group produces a measurable decline in the outcome it was meant to drive.
• Users describe it, unprompted, when explaining why they prefer the product.

Features that cannot pass any of these tests are candidates for removal, regardless of how much care went into designing them. The goal is a product where every original decision is doing work, and the test for that is behavioural, not internal opinion.

Conclusion

The copy-versus-create question does not have a universal answer, but it does have a reliable method for finding the right one in each case. The method is to understand, specifically, what a feature is doing for users in its original context, and whether that context transfers to yours. If it does, adopt the pattern and spend your energy elsewhere. If it does not, design for the context you actually have.

What the football founder's spreadsheet could not do was tell him whether any of those features were landing. It could not tell him what his prospective users felt when they opened a competitor app, what frustrated them, or what made them stay. That information only comes from talking to people, and the discomfort of doing that, the possibility that the idea might need adjusting, is precisely why so many reach for the spreadsheet instead.

Building something distinctive requires accepting that some of your original decisions will not work and some borrowed patterns will serve your users better than anything bespoke could. The teams that navigate this well are the ones who hold their feature decisions lightly enough to test them and honestly enough to change them. Products built on that discipline tend to earn the kind of retention that a feature checklist was never going to produce.

If you are working through a product decision like this and want a clear perspective on where to invest your differentiation effort, let's talk about your product strategy.

Frequently Asked Questions