How Can I Tell If a New App Feature Is Worth Building?

I've built hundreds of features over the years—some that users absolutely loved and some that, well, nobody used at all. And I mean nobody. It's a bit mad really, how you can spend weeks or even months building something that seemed like a brilliant idea at the time, only to watch it gather dust in your app whilst users completely ignore it. The truth is that deciding which features are worth building is one of the hardest parts of app development; its not just about having good ideas, its about knowing which good ideas deserve your time and money.

Here's the thing—most app teams have a massive backlog of feature requests. They come from everywhere: users sending feedback, your sales team promising things to close deals, competitors launching something new that makes you panic, or just your own team sitting around brainstorming. The list gets longer and longer, and suddenly you're drowning in possibilities without a clear way to choose what actually matters.

Every feature you build has a real cost attached to it, and I'm not just talking about the development hours or the money spent building it

But here's what I've learned after building apps for startups, scale-ups and big brands—you can't build everything. You shouldn't build everything. Actually, the best apps are often the ones that do fewer things really well rather than lots of things poorly? The challenge is figuring out which features will genuinely move the needle for your business and your users, and which ones are just nice-to-haves that will dilute your focus. This guide will walk you through the exact process I use with clients to validate features before we write a single line of code...because nobody wants to waste six months building something that nobody needs.

Understanding the Real Cost of Building Features

When someone says "lets just add this feature", I have to bite my tongue a bit. Because what they're really saying is "lets spend thousands of pounds and several weeks of development time on something that might not even work." The true cost of building a new feature goes way beyond what you pay your developers—and honestly, most people get this bit completely wrong.

First up, theres the obvious stuff: design time, development time, testing time. A simple feature might take 40-80 hours of work, which at agency rates means anywhere from £3,000 to £8,000. But here's the thing—that's just to build it. You've also got to maintain it forever, which means every future update needs to account for this feature; every bug fix needs to consider how it interacts with everything else, and every new developer who joins your team needs to understand how it works.

The Hidden Costs Nobody Talks About

Then you've got the sneaky costs that add up fast. Technical debt, for one. Rushed features create messy code that slows down future development. I've seen projects where adding a new feature takes twice as long as it should because the codebase is cluttered with half-baked ideas from years ago. App performance is another big one—more features mean larger app size, slower load times, and potentially more crashes. Users actually notice this stuff.

What It Really Means for Your Users

But the biggest cost? Complexity. Every new feature makes your app harder to use, harder to navigate, and harder to understand. You might think you're adding value, but you could be making the experience worse for the people who actually use your app every day. Sure, power users might love advanced features, but what about everyone else? The data shows that apps with simpler interfaces have better retention rates—and thats what really matters in the end.

Listening to Users Without Getting Lost

User feedback is like gold dust for app developers—but here's the thing, not all feedback is actually useful. I mean, sure, listening to your users seems obvious right? But you'd be surprised how many teams either ignore their users completely or do the opposite and try to build every single thing that gets requested. Both approaches will kill your app, just in different ways.

The real skill is learning which feedback to act on and which to file away in the "interesting but not now" folder. When a user tells you they want a specific feature, what they're really doing is telling you about a problem they have. Your job isnt to build exactly what they asked for—its to solve the actual problem. Sometimes the solution they suggest is spot on; other times its completely off the mark.

I've seen teams spend months building features that users swore they desperately needed, only to launch them and find...crickets. Nobody uses it. Why? Because the team built what users said they wanted instead of what they actually needed. This happens all the time and honestly, it's a bit maddening to watch. Knowing which features to prioritise when users ask for more is absolutely crucial to avoiding this trap.

How to Collect Feedback That Matters

You need multiple channels for gathering user input, but each channel tells you something different. In-app surveys catch people when they're actively using your product; support tickets show you where things are breaking down; app store reviews (particularly the 2-3 star ones) reveal honest frustrations that passionate users and haters both miss. Understanding when to ask users to rate your app can help you gather more balanced feedback rather than just complaints.

But here's what most people get wrong—they look at the number of requests for a feature and assume that's the priority. "50 people asked for dark mode, only 10 asked for better search, so dark mode wins!" Not so fast. Those 50 people asking for dark mode might just be very vocal, whilst thousands of users are quietly struggling with search and just...leaving your app instead of complaining about it.

The Questions That Cut Through the Noise

When you're reviewing feedback, ask yourself these questions about each request:

• What problem is this person actually trying to solve?
• How many users likely have this same problem, even if they haven't mentioned it?
• Is this problem stopping people from getting value from the app, or is it just annoying?
• Would solving this make the app more valuable to existing users or help attract new ones?
• Does this align with where we want to take the product long-term?

That last question trips people up. You know what? Sometimes users ask for things that would genuinely help them but would take your app in a direction you don't want to go. A fitness tracking app could add meal planning, social networking, a marketplace for trainers—but should it? Each feature pulls you further from your core purpose and makes your app harder to maintain and market.

Create a simple spreadsheet to track feature requests. Include columns for: the request, the underlying problem, how many users mentioned it, potential impact (high/medium/low), and alignment with your product vision. Review it monthly, not daily—you need distance to see patterns clearly.

The users who give you the best feedback aren't always the loudest ones. Sometimes its the person who sends a thoughtful email explaining exactly what they were trying to do when they got stuck. Sometimes it's the data showing that 60% of new users abandon the app at the same exact point in their journey. Pay attention to both what people say and what they do—when there's a gap between the two, the behaviour usually tells you more than the words.

The Data That Actually Matters

Right, so you've got analytics set up in your app—great. But here's the thing, most teams are drowning in data whilst somehow still missing the information that actually tells them what to build next. I've seen dashboards with hundreds of metrics that look impressive but don't answer the basic question: should we build this feature or not?

The metrics you really need fall into three categories, and they're probably simpler than you think. First up is engagement data—not just how many people use your app, but how often they come back and what they're trying to do when they're there. If users are repeatedly visiting a certain section or attempting an action that doesnt exist yet, that's a signal worth paying attention to. Second is completion rates; basically, when people start a task in your app, do they finish it? Low completion rates often point to friction that a new feature could solve. And third—this one gets overlooked constantly—is support ticket volume. If your support team is answering the same question fifty times a week, you might need a feature rather than better documentation. Understanding what metrics to track for real app growth will help you focus on the data that actually drives feature decisions.

But here's what drives me mad: teams obsessing over vanity metrics like total downloads or daily active users when making feature decisions. Those numbers are great for investors, sure, but they won't tell you if your checkout flow needs a one-click payment option or if your users actually want that social sharing feature you're excited about. You need to look at behaviour, not just presence. Are users exhibiting the problem that your proposed feature would solve? That's the data that matters. Everything else is just noise that makes you feel busy without helping you make better decisions about what to build next.

Testing Before You Build

Right, so you've got a feature idea that seems promising—but here's where most teams make a massive mistake. They jump straight into development without actually testing whether people want it. I mean, I get it, the excitement of building something new is real, but you can save yourself months of wasted effort (and a whole lot of money) by testing first. Deciding which app features to test during planning can save you from building something nobody wants.

The simplest way to validate app features? Create a prototype. Not a working feature, just something that looks like it works. You'd be surprised how much you can learn from showing people a few screens and watching them try to use it. We use tools like Figma or InVision to create these—they're basically clickable mockups that feel real enough to get genuine reactions. When users click around and tell us what they expect to happen, we discover all sorts of problems we never thought of.

Testing a feature idea shouldn't take months or cost thousands—sometimes a simple prototype and five user interviews can tell you everything you need to know

Another trick I use a lot is the fake door test. You add a button or menu item for the new feature in your existing app, but when someone taps it they just see a message saying "coming soon" or asking if they'd like to be notified when its available. If hardly anyone clicks it? Well, that tells you something important doesn't it. If loads of people click it and sign up for updates, you've got validation worth paying attention to.

Landing pages work the same way for features—create a simple page describing what the feature does, run some ads to your target users, and see if they're interested enough to sign up or learn more. Its MVP development at it's finest, testing demand before you invest in supply. The data from these tests is way more reliable than asking people "would you use this?" because you're measuring actual behaviour, not hypothetical interest.

Making Sense of Your Competition

Right, lets talk about what your competitors are doing—because honestly, they're probably watching you too. I spend a lot of time looking at competitor apps before we build any new feature, and its amazing how much you can learn just by being nosy. But here's the thing; copying what your competitors do isn't a strategy, its a recipe for being second best.

What I actually do is download every competitor app in the space and use them properly. Not just a quick five-minute browse, I mean actually going through their onboarding, testing their core features, seeing where they excel and where they frustrate users. You'd be surprised how many "successful" apps have glaring problems that users complain about in reviews. Those complaints? They're gold dust for you.

What to Look For When Analysing Competitors

When I'm doing competitor research, I'm looking at specific things that tell me what's working and what isn't. The app store reviews are your best friend here—users will literally tell you what features they love and what features they wish existed but don't. Look at the 2 and 3-star reviews especially; they're more honest than the 1-star rants or 5-star cheerleading.

• Which features do users mention most in reviews (positive or negative)?
• What's their onboarding process like and where does it lose people?
• How often do they update their app and what do they add?
• What's their monetisation strategy and are users complaining about it?
• Where do they seem to be investing resources based on recent updates?

But I'll be straight with you—just because a competitor has a feature doesn't mean you need it. Sometimes they've built something that looks impressive but doesnt actually move the needle for their business. I've seen apps add fancy features that nobody uses because they were chasing their competition instead of serving their users. The smart move? Find the gaps in what competitors offer and decide if those gaps are worth filling or if they exist for good reason.

When to Say No to Good Ideas

This is probably the hardest part of building an app, and I mean that. Saying no to features that sound brilliant, that users are asking for, that your team is excited about—its tough. Really tough. But here's the thing—just because an idea is good doesn't mean it's good for your app right now. I've seen more apps damaged by adding too many features than by having too few, and that's not an exaggeration.

Every feature you add makes your app more complex. More code to maintain. More bugs to fix. More things that can go wrong. And—here's what people often miss—more things for new users to learn before they understand what your app actually does. You know what? Sometimes the best decision you can make is to protect your app from becoming bloated with features that dilute its core purpose.

Red Flags That Mean You Should Say No

Over the years I've developed a bit of a checklist for when to turn down features, even good ones. These red flags have saved me (and my clients) from making some pretty costly mistakes:

• The feature serves less than 20% of your user base—building for edge cases is expensive
• It doesn't directly support your app's main purpose or your business goals
• You cant measure whether it's actually working once its built
• It requires ongoing maintenance that'll drain resources from more important work
• Users are asking for it but their behaviour suggests they wouldn't actually use it
• It adds complexity to the core user journey or makes your main features harder to find
• The development time could be better spent fixing existing problems

One of my clients wanted to add a social sharing feature because "everyone has it"—but their data showed users valued privacy above everything else. We said no, and six months later their retention was still climbing because we'd focused on the features that actually mattered to their audience instead.

Create a "parking lot" document for good ideas that don't make the cut right now; this way you're not losing them forever, just deferring them until they make more sense for your app's development stage.

Building Your Feature Roadmap

Right, so you've done the research, tested your ideas, talked to users, looked at the data—now what? This is where most teams either create something brilliant or end up with a roadmap that looks like someone threw darts at a board whilst blindfolded. And I've seen both happen more times than I care to admit.

Here's the thing about roadmaps; they need to tell a story. Not a complicated one, just a clear path from where you are now to where you want to be. I usually split mine into three buckets: must-haves (the stuff that keeps the lights on), should-haves (features that move the needle), and nice-to-haves (things we'd love to do but can wait). Its simple, but it works.

Prioritising Without Losing Your Mind

When I'm working out what goes where, I look at three things—impact, effort, and timing. Impact is obvious; how much will this feature actually matter to users and to the business? Effort is about development time and resources (and yes, that includes the hidden costs we talked about earlier). But timing? That's the one people forget. Sometimes a feature makes perfect sense but the market isn't ready for it yet, or maybe you need to build something else first to make it work properly.

Making It Real

Your roadmap should be a living document, not something carved in stone. I update mine every quarter based on what we've learned. Did that feature we built last month perform how we expected? No? Then maybe we need to rethink what's coming next. The best roadmaps leave room for surprises—both good ones and bad ones. Because trust me, there will be both.

Conclusion

Look, deciding which features to build isn't something you can just wing—I've seen too many apps fail because they built everything that sounded good rather than what actually mattered. The truth is, feature validation is about discipline; its about saying no more often than you say yes, and being okay with that. When you understand the real costs (both time and money), listen to your users properly, pay attention to the right data, and test before you commit, you're already ahead of most apps out there.

What I've learned over the years is that the best product teams treat their roadmap like a living document. It changes. It evolves. Sometimes you'll make the wrong call and that's fine—you learn from it and move on. The key is having a process that helps you make informed decisions rather than emotional ones. Because let's be honest, we all get attached to our ideas sometimes, but the market doesn't care about our feelings...it only cares about whether we're solving real problems.

I mean, you've now got the tools to validate app features properly, to prioritise what matters, and to test your assumptions before spending months building something nobody wants. MVP development isn't just about launching quickly—it's about learning quickly. And that's what separates apps that succeed from those that drain budgets and never find their audience. Start small, validate relentlessly, and only build what you can prove is worth building. That's how you create something people actually use rather than just download once and forget about. The apps that win aren't always the ones with the most features; they're the ones that built the right features at the right time for the right reasons.