Should I Build Features My Competitors Have or Create Something New?

You know what question I get asked more than almost any other? Should I build the same features my competitors have, or should I try something completely different? It's a fair question really—and one that doesn't have a simple answer. I've built apps across healthcare, fintech and e-commerce over the past nine years, and I can tell you this dilemma keeps founders and product managers awake more nights than just about anything else. Here's the thing though; the apps that succeed aren't always the ones with the most features or the most original ideas—they're the ones that understand why they exist in the first place.

When you look at your competitors' apps, its tempting to make a list of everything they've got and assume you need it all too. I mean, if they've got a feature, surely its there for a reason? But I've seen this approach fail more times than I can count. A fintech client once came to me wanting to replicate every single feature from three different banking apps—the project would've cost them nearly £400,000 and taken over a year to build. We ended up focusing on just two features their competitors didn't do well, and the app launched in four months for less than half that budget. Six months after launch, they had better retention rates than any of their larger competitors.

The question isn't whether to copy or innovate—it's about understanding which features actually solve problems your users care about and which ones are just noise

This guide will walk you through how to make these decisions based on real data, user needs, and market positioning rather than guesswork. Because honestly? Getting this wrong is expensive, time-consuming, and can kill an otherwise good app idea before it even gets started.

Understanding What Your Competitors Are Actually Doing

Right, so before you decide whether to copy your competitors or blaze your own trail, you need to actually understand what they're doing and why its working (or not working). I mean, most people download a few competitor apps, click around for ten minutes, and think they've done their research. But that's like looking at a restaurant menu and thinking you understand their entire business model—there's so much more happening beneath the surface.

When I'm helping clients analyse their competition, we go deep. Really deep. I'm talking about installing every competitor app in your space and using them daily for at least two weeks. You need to see their onboarding flow, their push notification strategy, how they handle errors, where they're pushing users to upgrade or make purchases. One fintech client came to me wanting to copy a competitor's loan application process because "it looked simple." After proper analysis, we discovered that simple interface had a 60% drop-off rate according to their public investor reports—turns out simple doesn't always mean effective, does it? This is exactly why researching competitors without copying their mistakes is so crucial.

What to Actually Look For

Here's what I examine when doing competitive analysis; these are the things that actually matter:

• User onboarding flow—how many steps, what information they collect, where users might drop off
• Core feature set—not just what they have, but how they've prioritised things in the navigation
• Monetisation strategy—when do they ask for payment, what's free vs paid, how aggressive are the prompts
• Push notification patterns—frequency, timing, personalisation level (this tells you loads about their retention strategy)
• App store reviews—not the ratings, but what people are actually complaining about or praising
• Update frequency—check their version history to see how often they ship new features
• Performance metrics—loading times, crash rates, how they handle poor connectivity

But here's the thing that most people miss entirely. You need to look at what your competitors aren't doing just as much as what they are doing. I worked with a healthcare app client who noticed all their competitors required lengthy registration processes before users could access any content. By allowing users to explore the app first and register later, they saw a 40% increase in completed registrations. Sometimes the biggest opportunities are hiding in plain sight because everyone's just following the same tired playbook.

Understanding the Why Behind Their Choices

Features don't exist in isolation—they're responses to specific problems or market conditions. When you see a competitor with a particular feature, ask yourself why they built it. Was it user-requested? Are they trying to solve a specific pain point? Or are they just copying someone else? I've seen so many apps with features that clearly exist because "everyone else has them" rather than because they serve any real purpose. A food delivery app I worked on nearly copied a competitor's elaborate meal planning feature until we dug into the data and found almost nobody used it; the competitor had spent six months building something that less than 2% of their users even opened. That kind of insight saves you months of wasted development time and honestly, quite a bit of money too.

Why Copy-Pasting Features Usually Backfires

I've watched this happen more times than I care to count—a client shows me their competitor's app and says "we need everything they have, plus these three extra things." Sounds logical, right? If your competitor has 50 features and you build 53, you win. Except that's not how it works, and I've seen this approach drain budgets faster than anything else in mobile development.

The biggest problem with copying features is that you're always playing catch-up. While you're building their feature set from six months ago, they've moved on to something new. I worked on a healthcare app where the client wanted to match a competitor's symptom checker, appointment booking, and medication reminders. Took us four months to build. By launch, the competitor had pivoted to focus solely on appointment booking—and honestly, their streamlined approach was converting better because users weren't overwhelmed with options they didn't need.

But here's what really kills copy-paste strategies: you end up with features that weren't designed for your users. A fintech client once insisted on copying a competitor's investment portfolio tracker because "everyone has one." Problem was, their users were mostly first-time savers who found the feature intimidating. It sat there unused, costing £40k to build and another £8k yearly to maintain. When we finally removed it and added a simple savings goal tracker instead, engagement went up 34%. Before building any feature, you need to understand if a feature will actually make you money rather than just drain your budget.

The Hidden Costs Nobody Mentions

Every feature you add creates technical debt. More code to maintain, more things that can break, more complexity in your codebase. I've seen apps become so bloated with copied features that simple updates took three times longer than they should. One e-commerce app I inherited had 23 different ways to search for products—each copied from different competitors over two years. The app crashed constantly because all these features were fighting for resources. This is why understanding how to keep your app working when updates break things becomes increasingly important as you add complexity.

Your users don't want feature parity; they want their problems solved elegantly. When you copy features, you're solving someone else's user problems, not yours. The education app market taught me this lesson well—we built a learning management system that copied all the standard features from competitors (forums, grade books, assignment uploads, video lessons). Users complained it was "too complicated" even though we had everything the market leader offered. Turns out, our users were primarily adult learners who just wanted bite-sized lessons they could complete on their commute. We stripped out 70% of the features, focused on that one use case, and retention doubled.

When Features Look the Same But Work Differently

Sometimes features appear identical on the surface but serve completely different purposes under the hood. I built push notification systems for two different apps—looked the same to users, but one was designed for time-sensitive alerts (a delivery app) and the other for gentle engagement prompts (a meditation app). If the meditation app had copied the delivery app's aggressive notification strategy, users would've uninstalled immediately. Context matters more than the feature itself.

Another thing people miss: your competitor's features might actually be their mistakes. I can't tell you how many times I've analysed competitor apps and found features with terrible engagement metrics that they're probably desperate to remove but can't because users expect them now. You have the advantage of starting fresh—don't waste it by inheriting someone else's legacy problems.

Before building any feature from a competitor, ask yourself: do we know for certain this feature is successful for them? Can we access their engagement data? Do our users have the same needs? If you're answering no to these questions, you're building blind.

The apps that win aren't the ones with the longest feature lists. They're the ones that do a few things exceptionally well and give users a clear reason to choose them over alternatives. When you copy features, you're actively avoiding the hard work of figuring out what makes your app worth using. That's the work that actually matters.

Finding Your Unique Value Proposition

This is where things get interesting—finding what makes your app different isn't about sitting in a room brainstorming clever taglines. Its about understanding the gaps your competitors have left open, whether they meant to or not. I worked on a fitness tracking app where the client was obsessed with matching every feature the big players had; calorie counting, step tracking, social sharing, the works. But when we actually spoke to their target users (busy parents in their 40s), we found something the competitors had completely missed—these people didn't want another app shouting at them about daily goals. They wanted gentle encouragement and flexibility. So we built that instead. The app didn't have half the features of MyFitnessPal, but its retention rate was nearly double what we'd projected. Understanding which user problems are worth solving becomes critical when you're trying to differentiate from competitors.

Your unique value proposition doesn't need to be revolutionary? It just needs to be yours and actually useful. I mean, look at how many meditation apps exist—but Headspace succeeded because they focused on being approachable and not too spiritual, whilst Calm went the opposite direction with nature sounds and sleep stories. Same problem, completely different solutions, both successful. The mistake I see constantly is thinking your value prop has to be a single killer feature; sometimes its the combination of how you do things, who you do them for, or the specific pain point you prioritise.

When you're trying to pin down your value prop, start by listing what your competitors do well, then identify who they ignore or underserve. I built a property search app for a client who couldn't compete with Rightmove's listings volume—that would've been mad. Instead, we focused on first-time buyers who were overwhelmed by the process and needed guidance, not just listings. That specific focus became their value prop, and it worked because we weren't trying to be everything to everyone.

When It Makes Sense to Match Competitor Features

Look, I'm not going to pretend that building what your competitors have is always a bad idea—because it isn't. There are specific situations where matching features is absolutely the right call, and I've advised clients to do exactly that more times than I can count. The trick is knowing when you're establishing baseline expectations versus just being lazy with your product strategy.

Table stakes features are the ones users expect to see in every app in your category. When I worked on a fintech app a few years back, the client wanted to skip fingerprint authentication because they thought it made them "too similar" to their competitors. I had to explain that biometric login wasn't a differentiator anymore—it was a security baseline. Users weren't going to see its absence as unique; they'd see it as a red flag. And they'd probably delete the app before funding their account.

Core Functionality Users Expect

Think about food delivery apps for a second. Real-time tracking, saved addresses, previous order history—these aren't features that make you special anymore. They're features that keep you in the game. I mean, could you imagine opening Deliveroo and not being able to see where your driver is? You'd probably think the app was broken.

If every competitor offers a feature and users consistently mention its absence in your reviews or support tickets, that's your market telling you it's non-negotiable

When Playing Catch-Up Makes Business Sense

Sometimes you need to match features just to stop the bleeding. I worked with an e-commerce client who was losing customers because they didn't offer Apple Pay while their three main competitors did. Was Apple Pay going to be their secret weapon? No. But its absence was actively costing them conversions—their checkout abandonment rate dropped by 23% once we added it. That's the kind of matching that pays for itself immediately... and honestly, we should have done it six months earlier.

How to Decide Which Features Actually Matter

I've watched countless startups blow through their entire budget building features nobody asked for, and its genuinely frustrating because most of the time it could've been avoided. The trick is to separate what users actually need from what stakeholders think would be "nice to have"—these are two very different things, trust me. When we built a healthcare app for a client a few years back, they wanted video consultations, appointment scheduling, prescription refills, a symptom checker, and about fifteen other features. The budget? Enough for maybe three of those done properly. We had to make some tough calls.

Start by looking at your user data if you have any—what are people trying to do in your app right now? Where are they getting stuck or dropping off? If you don't have an existing app, talk to potential users (actual ones, not just your mates). I mean really talk to them. Not "would you use this feature" questions because everyone says yes to those, but "show me how you currently solve this problem" conversations. You'll learn more in thirty minutes of watching someone struggle through their current workflow than you will from a hundred survey responses. This type of research is fundamental to building personas when every user seems different, which helps prioritise features more effectively.

The Priority Framework That Actually Works

Here's how I help clients prioritise features; its not fancy but it works. Create a simple table with four columns—feature name, user impact (high/medium/low), development effort (hours or weeks), and business value. Then be brutal about it. A feature might seem brilliant but if its high effort with low user impact? It goes to the bottom of the list, or off it entirely.

What Users Say vs What They Do

One massive mistake I see is building features based on what users say they want in interviews or surveys. People are terrible at predicting their own behaviour—they'll tell you they want detailed analytics and custom reports, then never look at them once. With that fintech app I mentioned earlier, users kept asking for complex budgeting tools with categories and subcategories and projections. We built a simpler version first (just showing where money was actually going) and guess what? That's all most people used. The fancy stuff got less than 5% engagement. For context, budget tracking apps cost significant money to build, so getting the features right the first time is crucial.

Look at behaviour metrics instead. What features do users in competitor apps actually use regularly? Not what gets mentioned in app store reviews, but what the retention data shows. If you're building a fitness app and everyones competitor has nutrition tracking, but the data shows most users abandon it after a week... maybe you don't need to match that feature after all. Maybe there's a simpler approach that actually sticks.

Also—and this might sound obvious but its often ignored—consider what you can realistically support after launch. Building a chat feature sounds straightforward until you realise you need moderation, customer support for when messages don't send, data storage compliance, and probably push notifications. That "simple" feature just became a full-time job for someone on your team. I've seen apps launch with features they couldn't properly maintain, and it damaged their reputation more than not having those features would have.

Building Something New Without Losing Your Users

The truth is, building something completely different from your competitors is exciting but scary as hell. I've worked with clients who wanted to revolutionise their entire industry with a never-before-seen feature set, and while some succeeded, others watched their user base shrink because they'd changed too much too quickly. The trick isn't avoiding change—its making sure your users come along for the ride.

When we rebuilt a healthcare booking app that had been around for three years, we knew we needed to add some unique features the competition didn't have. But we also knew that if we removed the familiar appointment calendar view that users loved, we'd lose them. So we kept the core navigation exactly where it was and introduced the new AI-powered symptom checker as an optional feature. Users could discover it naturally without feeling forced. Within two months, 40% of active users had tried the new feature because they felt in control of when and how they explored it.

What Users Actually Need During Change

Here's what I've learned about introducing new features; people hate surprise changes but love feeling like they discovered something valuable. When you're building something your competitors don't have, you need to maintain what I call "anchor points"—the familiar bits that users rely on. For a fintech app we developed, we kept the transaction history view identical whilst adding a completely new budgeting tool that appeared as a small card users could expand. No forced tutorials. No takeover modals. Just a gentle "Hey, this might help you" approach. When designing these interface elements, we used principles from designing cards that users want to tap to ensure engagement felt natural.

Run a beta test with 5-10% of your user base before rolling out major changes. Watch their behaviour data more than their survey responses—people will tell you they love something new but then never use it.

The Staged Introduction Approach

I always recommend breaking down new features into stages. You don't need to launch everything at once, and honestly you probably shouldn't. We built an e-commerce app that introduced social shopping features (something their competitors weren't doing) over four months rather than all at once. First month was just the ability to save items to shareable lists. Second month added following other users. Third month introduced live shopping events. By the time we hit month four with full social feeds, users had gradually adopted each piece and it felt natural rather than overwhelming. We were careful about timing our sharing prompts throughout this process, following best practices for how often to ask users to share the app without being pushy.

The mistake I see most often? Treating feature launches like product launches. Your existing users aren't starting fresh—they already have habits and workflows they're comfortable with. When you introduce something new, you're asking them to learn and adapt. Make that process as painless as possible by keeping the things they use daily exactly where they expect them to be.

Here's my standard process for introducing unique features without losing users:

• Identify the three most-used features in your current app and commit to not moving or significantly changing them
• Introduce new features as optional additions rather than replacements—let users discover them naturally
• Use subtle prompts (like small badges or cards) rather than intrusive tutorials that block the main interface
• Monitor usage data weekly during the first month and be ready to adjust based on actual behaviour, not assumptions
• Provide an easy way for users to dismiss or hide new features if they're not interested—this builds trust
• Keep documentation simple and visual; most users won't read lengthy explanations about why you built something

One finance app we worked on had massive user pushback when they tried to replace a simple expense tracker with a more complex budgeting system. Users felt like something was being taken away from them. We rolled back the change and instead kept the old tracker whilst adding the new system as a separate section. Problem solved. Sometimes the answer really is that simple—don't take away, just add alongside.

The businesses that succeed with truly different features are the ones that give users time and choice. You're not trying to trick people into using something new; you're showing them something valuable and letting them decide when they're ready to try it. That might take weeks or months, but its better than losing half your user base because you forced change too quickly.

Testing Your Feature Strategy Before Full Development

Here's something I wish more founders understood—you don't need to build the entire feature to know if its worth building. I mean, why spend £50,000 and six months developing something when you can test the core concept in a couple of weeks? Over the years, I've seen too many apps invest heavily in features that seemed brilliant on paper but completely flopped with actual users. The smart approach? Test before you commit.

One of my favourite methods is the fake door test. Basically, you add a button or menu item for the feature in your existing app, but when users tap it they see a message saying "Coming soon! Would you like early access?" then capture their email. If nobody clicks it, you've just saved yourself a fortune. I used this with a fitness app client who wanted to add meal planning—turns out only 3% of users even clicked through, which told us the feature wasn't as important as we thought. We pivoted to something else entirely.

Another approach that works brilliantly is the concierge method, especially for complex features. You manually perform what the feature would do automatically. I did this with a property management app where landlords wanted automated rent reminders. Instead of building the automation straight away, we had someone send the reminders manually for three months. This helped us understand exactly what information landlords needed, what timing worked best, and whether they'd actually use it (they did, religiously). This approach also helps you understand how to show your app will make money before investing in full development.

Quick Testing Methods You Can Use Tomorrow

• Prototype testing with clickable mockups—tools like InVision let users navigate a fake version of your feature so you can watch where they struggle
• Beta groups with your most engaged users—give them early access to a basic version and actually listen to their feedback (not just the positive stuff)
• Landing page validation—create a simple webpage explaining the feature and track conversion rates before building anything
• Analytics review—look at your existing data to see if users are trying to do what your new feature would enable
• Competitor app testing—download competitor apps and use them extensively to understand what users already expect

The mistake I see constantly is treating feature development like an all-or-nothing decision. It's not. You can build a minimal version that tests the core hypothesis without all the bells and whistles. For a healthcare app we developed, the client wanted video consultations with fancy features like screen sharing and file transfer. We started with basic video calls only—turned out patients just wanted to see their doctor's face, they didn't care about the extra stuff. We saved months of development time by testing the simple version first.

What Good Testing Data Actually Looks Like

Don't just collect numbers, understand what they mean. If 40% of users click on your fake door test, that's genuinely promising. If 5% do, you need to dig deeper—maybe the feature itself is fine but your messaging is rubbish? I worked with an e-commerce app where initial tests showed low interest in a wishlist feature. But when we changed the button from "Save for Later" to "Create Wishlist" engagement jumped to 35%. The feature was right, the presentation wasn't. This is similar to how small changes in your app store listing can impact downloads, which you can measure through app store optimization testing.

Time-based testing matters too. Don't run a test for two days and call it done. I typically recommend at least two weeks for fake door tests and a full month for beta features. You need enough data to account for different usage patterns—weekday vs weekend users, morning vs evening sessions, that sort of thing. And honestly? Sometimes the data will tell you things you don't want to hear. That's the whole point though, isn't it? Better to know now than after you've spent six months building something nobody wants.

Conclusion

After building apps across healthcare, fintech, e-commerce and more, I can tell you that the competitor feature question never really goes away. You'll face it at launch, six months in, and two years down the line when a new player enters your market. The answer isn't about choosing one approach over the other—it's about knowing when to match and when to diverge based on your specific user needs and market position.

I've seen apps fail because they tried to be too different, confusing users who just wanted the basics to work properly. And I've watched apps disappear into obscurity because they offered nothing you couldn't get elsewhere. The sweet spot? Match expectations on the features that matter for trust and usability (like security features in fintech or checkout flows in e-commerce), then differentiate where it creates genuine value for your users. Not flashy value. Real value.

Here's what I do now with every project: we map competitor features, sure, but we spend more time talking to actual users about their frustrations. Those conversations reveal gaps that competitive analysis alone never will. Maybe its a payment feature that takes too many taps. Maybe it's a notification system that annoys rather than helps. These insights guide our feature roadmap far better than simply looking at what competitors offer.

Your app strategy needs to be flexible enough to adapt when competitors launch something users genuinely want, but confident enough to say no when they dont. Test your assumptions early, measure everything that matters, and remember that user retention beats feature quantity every single time. The apps that succeed long-term are the ones that understand their users better than anyone else—not the ones with the longest feature list.