Why we removed the photo upload.

Process · 6 min read

During the design of an NDIS life management app, we had a feature on the list that seemed like a no-brainer: photo uploads. Let users attach photos to their task entries, their notes, their daily activities. It sounded useful. The client wanted it. It seemed like a quick win.

We removed it. And the app was better for it. Here's why, and what it taught me about the hardest part of building a good product.

Most features feel necessary until you test them

When you're building an app, every feature feels justified in isolation. Photo uploads? Of course. Who wouldn't want that? But features don't exist in isolation. They exist inside a product that has to be learned, maintained, and used under real-world conditions. And every feature you add has a cost that goes beyond development time.

Research from Pendo, which tracks product usage across thousands of apps, found that 80% of features in the average software product are rarely or never used. The Standish Group found similar numbers: 64% of features delivered in software projects are rarely or never used by the end users they were built for.

That's not a failure of the users. It's a failure of the process. We build features because they sound good in a meeting room, not because we've validated that real users need them in their daily workflow.

What the photo upload actually cost

When we mapped out what photo uploads would actually require, the list was longer than expected. Camera and photo library permissions. Image compression and upload handling. Storage infrastructure on the backend. A gallery or viewer for reviewing uploaded photos. Considerations for users on limited data plans. Accessibility requirements for screen readers to describe uploaded images. Privacy implications for photos that might contain sensitive information.

Each of those items isn't just a development task. It's ongoing maintenance. Storage costs money. Permissions need to be managed. Photo moderation might be needed depending on the context. What seemed like a simple feature was actually a significant commitment of development budget, time, and ongoing resources.

And when we tested with actual users, most of them didn't need it. The tasks they were logging were simple daily activities: medication reminders, appointments, household tasks. A text description was sufficient. The photo upload was a solution looking for a problem.

The courage to remove things

Removing a feature feels wrong. It feels like you're making the product worse. Every instinct tells you to add, not subtract. But research published in the Harvard Business Review has shown that feature bloat is one of the primary reasons users become dissatisfied with products over time. The researchers found that while more features attract buyers initially, they lead to lower satisfaction once the product is actually used. They called it "feature fatigue."

The Project Management Institute found that 52% of projects experience scope creep, and it's consistently identified as one of the top causes of project failure. Every feature you add to version one that doesn't need to be there is scope creep, even if it was in the original plan.

The best products are defined not by what they include, but by what they have the discipline to leave out. Apple didn't ship the first iPhone with copy and paste. Instagram launched with just photo sharing and filters. The MVP approach isn't about shipping something incomplete. It's about shipping something focused.

How to decide what stays and what goes

For every feature on your list, ask three questions. Does this directly support the core thing the user came to do? If the answer is no, it's a candidate for removal or deferral. Can the user achieve their goal without this feature? If yes, it can wait for a later version. Is this solving a real problem we've observed, or is it something we assume people will want?

The difference between a feature and a solution is critical here. Features are things the product does. Solutions are outcomes the user needs. Start with the outcomes and work backwards. You'll find that many of the features on your list are nice-to-haves disguised as must-haves.

Testing is the ultimate arbiter. Put your prototype in front of real users. Watch what they use, what they ignore, and where they struggle. The data will tell you what to keep and what to cut. And it will do so more reliably than any meeting room brainstorm.

You can always add it later

The photo upload isn't gone forever. If real users start requesting it, if the data shows there's a genuine need, it can be added in a future version. That's the beauty of the iterative approach. You're not making permanent decisions. You're making smart decisions about what matters now.

When you're self-funding, every dollar you don't spend on a feature nobody needs is a dollar you can spend on marketing, on user feedback, on the features that actually matter. That's not cutting corners. That's building smart.

Sources
Pendo - 80% of features in the average software product are rarely or never used.
Standish Group CHAOS Report - 64% of delivered software features are rarely or never used.
Harvard Business Review - "Defeating Feature Fatigue" - More features attract buyers but lead to lower satisfaction during use.
Pulse of the Profession (Project Management Institute) - 52% of projects experience scope creep.

Related blog posts:

The difference between a feature and a solution →

What is an MVP and why should your first app be one? →

Case study: NDIS life management app →