When to add features vs fix what you have
Every founder I've worked with has a feature list. Usually it lives in a Notes app, sometimes in a Notion board, occasionally scrawled on the back of a receipt. Dozens of ideas. New screens, new flows, new integrations, new things the app could do.
And every time a user complains or a metric dips, the instinct is the same: build something new. Retention dropping? Add a social feature. Engagement low? Add gamification. Revenue flat? Add a new premium tier.
Sometimes the right answer is genuinely a new feature. But most of the time, especially in the first 12 months, the right answer is to make what you already have work better. The difference between those two decisions is the difference between an app that grows and one that slowly drowns in its own complexity.
How feature creep actually kills apps
Feature creep doesn't kill apps in one dramatic moment. It's a slow bleed. Each new feature adds a little more complexity to the codebase, a little more surface area for bugs, a little more cognitive load for users. No single feature is the problem. The accumulation is.
I've seen this pattern repeat dozens of times. An app launches with a clean, focused experience. Users like it. Then the founder starts adding features based on user requests, competitor moves, and their own ideas. Six months later, the app has 3x more screens, the navigation is confusing, new users can't figure out what the app actually does, and the original value proposition is buried under layers of stuff.
Instagram started as a photo-sharing app with filters. Just that. If Kevin Systrom had launched with Reels, Stories, Shopping, Live, IGTV, and DMs all on day one, nobody would have downloaded it. The focused version got 25,000 users on launch day. The bloated version would have got zero.
A feature you build before it's needed is a feature that slows down everything else. Every line of code has a maintenance cost. Every screen has a support cost. Every option has a confusion cost.
The data tells you what to do (if you listen)
The good news is you don't need to guess. Your analytics will tell you exactly whether you need new features or need to fix existing ones. Here's what to look at.
Feature adoption rates
Pull up your analytics and look at what percentage of users actually use each feature you've already built. In most apps, the numbers look something like this:
- Core feature 1: 80% of users
- Core feature 2: 55% of users
- Feature 3: 20% of users
- Feature 4: 12% of users
- Feature 5: 4% of users
- Feature 6: 2% of users
This is the 80/20 rule playing out in real time. A small number of features drive the vast majority of usage. The features at the bottom? You probably spent weeks building them. Almost nobody uses them.
If you have features with single-digit adoption, adding more features is almost certainly the wrong move. Fix the ones people already use. Make them faster, smoother, more delightful. Or remove the ones nobody uses and simplify the experience.
Drop-off points in your funnels
Set up funnel analytics for your key user journeys. Signup to activation. Activation to first purchase. Browse to checkout. Whatever the critical paths are in your app.
Where are people dropping off? If 60% of users start your onboarding but only 25% complete it, you don't need a new feature. You need a better onboarding flow. If 40% of users add items to their cart but only 8% check out, you don't need more products. You need a smoother checkout.
The biggest growth opportunities almost always sit in fixing conversion between steps you already have, not in adding new steps.
User feedback themes
When users say "I wish the app could do X," founders hear "build X." But that's often the wrong interpretation. Read the feedback more carefully.
If 50 users ask for a calendar integration, maybe you need a calendar integration. But if 50 users are complaining that they can't find the scheduling feature you already built, you have a discoverability problem, not a feature problem.
Sort your feedback into two buckets:
- Users want something that doesn't exist: Genuine new feature territory. But only if the request aligns with your core value proposition and comes from a meaningful number of users, not just the three loudest ones.
- Users are frustrated with something that does exist: Fix territory. Polish the existing experience. This almost always has a higher ROI than building something new.
The fix-first framework
Before you add any new feature, run it through this checklist. If you can't answer "yes" to all five, you should probably be fixing what you have instead.
- Have 20% or more of your active users explicitly asked for this? Not "would find it useful" but actually requested it through feedback, support tickets, or interviews.
- Are your existing features performing above benchmark? If your core loop has below-average retention, fix that first. A new feature on top of a broken core is a waste of engineering time.
- Will this feature improve your north star metric? Not a vanity metric. Your actual north star. If you can't draw a clear line from "new feature" to "more revenue" or "better retention," think twice.
- Can you ship it in under two weeks? If a feature takes longer than two weeks to build, it's probably too big. Break it into smaller pieces and ship the smallest version first. See how users react before investing more.
- Does it simplify or complicate the experience? Some features genuinely simplify. A search bar in an app with 500 items makes things easier. But most features add complexity. Be honest about which category yours falls into.
When you should actually add a feature
I'm not saying never build new things. There are clear situations where a new feature is the right call.
You've hit a ceiling with your core loop
If your existing features are well-polished, adoption is high, retention is above benchmark, and growth has plateaued, you might genuinely need something new to reignite growth. This usually means your product has matured and users need a reason to engage more deeply.
Your data reveals a gap in the user journey
Sometimes analytics show a clear gap. Users are doing something your app wasn't designed for. They're exporting data to spreadsheets because you don't have reporting. They're screenshotting content because you don't have sharing. When users are hacking together workarounds, you've found a genuine feature opportunity.
A competitor move threatens your position
If a direct competitor launches a feature that your users start asking about, you need to respond. Not by blindly copying them, but by understanding whether that feature addresses a real need your users have. If it does, build your version. If it doesn't, ignore the noise.
Revenue unlock requires it
Sometimes the path to monetisation genuinely requires a new feature. You need payment processing to start charging. You need a premium tier to convert free users. These are strategic features tied directly to business outcomes, and they're worth building.
The 80/20 of product iteration
Here's the framework we use with our clients at Rebelled, and it's dead simple.
Spend 80% of your development time improving existing features. Performance, UI polish, bug fixes, smoother flows, better error handling, faster load times. The boring stuff that makes users think "this app just works."
Spend 20% on new features. And only features that passed the five-point checklist above.
Most founders do the exact opposite. 80% new features, 20% maintenance. They end up with an app that has 50 features, 40 of which are mediocre and 10 of which are broken. Users don't want 50 mediocre features. They want 5 that work brilliantly.
The best consumer apps in the world are obsessive about polish. They make you feel like every interaction was considered. Every animation is smooth. Every error state is handled gracefully. That level of quality comes from spending time on refinement, not from shipping features at speed.
Shipping fast is important in the early days. Shipping well is what keeps you alive after launch.
How to say no to feature requests
This is the hard part. Users ask for features. Investors suggest features. Your co-founder has feature ideas in the shower. Everyone wants to add things. Saying no feels like you're not listening.
But saying yes to everything is worse. It means you're letting other people set your product roadmap. You end up building a Frankenstein app that tries to please everyone and delights no one.
When someone requests a feature, say this: "I appreciate that. Can you tell me more about the problem you're trying to solve?" Half the time, you'll discover the underlying problem can be solved by improving something you already have. The other half, you'll get genuinely useful insight about what to build next.
Log every request. Categorise it. But don't act on any single request in isolation. Wait until you see patterns. Three people asking for the same thing is a data point. Thirty people asking for the same thing is a signal.
If you're in the thick of deciding what to build next and want a second opinion, grab a free game plan session. We do this every day, and sometimes an outside perspective cuts through the noise faster than another week of internal debate.
