Mobile development · Business Development

Adding a new feature to an existing app or create a different app?

Laura Aslan Consultant at Scriptofan Technologies Inc.

May 1st, 2015

Let's say you have already built an app, and, as things progress, you have new functionality in mind. That new functionality could become a new feature of the existing app, or, you could create an entirely new app containing that functionality.

How do you decide between these two options?

Becky Cruze Editor of "How to Start a Startup: The Book," Board Member of Women Get It Done

May 5th, 2015

I recently read about a pair of founders who left the Google Creative Lab to strike out on their own. They are really passionate about audio messaging and ended up creating a suite of apps meeting different use cases rather than one comprehensive app. In this interview, they talk about why they chose to create several different apps rather than just adding more features onto the first one. Hope it helps! http://thinkapps.com/blog/development/chhirp-cord-shhout-audio-messaging/

Ujjwal Trivedi

May 2nd, 2015

One of the important thing is to see where does the app lie in the broad problem-solution framework. If you are trying to solve a problem and the new feature still comes in the scope of solution it should be added to the current solution.

If however, it can prospectively be expanded to solve another problem for same or similar customer base, it makes sense to have a new app for it.

Please also check CAC and other pirate metrics to understand how and when can you break even with your new product, before you decide to go for it. This checklist of questions may be able to help you better.

Chris Carruth VP/Director. Strategy | Business Development | Operations | Product | Solutions

May 3rd, 2015

Agree with the comments that focus on the customer. Quick story..in previous role we had a whole slew of ideas for new products. Held a half a dozen "town hall meetings", i.e., 50-60 potential users in each meeting, equipped with electronic voting pads with a mic'd moderator upfront. Used storyboards, sketches and UI composites with goal of identifying/prioritizing what apps would be most successful.

One of many things we found...users often thing of features as part of a solution. Meaning, what was app1, app4 and app10 actually are features of a combined app which no one had completely thought of.

Lesson learned - know your consumer so you can frame out the possibilities..but don't think you are the consumer and end up missing the opportunities!

Jacob Johnson Artist and Creative Product Designer

May 1st, 2015

Depends on what the feature is and if it elevates your app or clogs it. The biggest problem I see with creating a new app from a feature of an existing one is the migration of the current users. If the feature fits well within the current application, then why not just add it as an additional awesomeness? You get the luxury of converting existing users, as well as none of the hassle of marketing an entirely new application; which in turn has it's own barriers like market fit and visibility...and it's not as simple as "just promo the new app inside the existing one". That being said, if your current users are low, and you feel that this feature is a beneficial pivot, then moving on from the old application to the new one could have the benefits of a fresh start without all the bloat of the old app. If it were me, of course depending on my current user base, I would add it as an additional feature. I come from gaming tho, so I'm not much help. heh ;)

Gil Allouche Founder @ Metadata

May 1st, 2015

from a marketing standpoint, creating a different app can get amazing results for marketing -- you can also seed the market/create buzz (see how-old.net, or hubspot site analysis tool or sidekick, or kissmetrics' tools etc) However, if it's tightly embedded in the product or an obvious feature that complements and offering but doesn't offer a whole lot of value independently -- it makes more sense to use it internally. Gil | metadata.io

Perri Gorman Founder of Archively & UnrollMe

May 1st, 2015

I think it totally depends on your addressable market and the customer. Are you building functionality because it is an evolution of what the user needs or are you building functionality because you have some new idea? I think you need to make decisions based on dialed in understanding of behavior.

Patrick Hidalgo

May 1st, 2015

If it is really just a feature, I wouldn't confuse current users with a new product download rather than an automatic upgrade. It could lead to brand mush.

Rajiv Unnikrishnan

May 1st, 2015

I agree with Patrick stick to the original app and add the feature to add.

It's easier to build and concentrate on one product .

Jared Hardy Founding Director at Data Roads Foundation

May 1st, 2015

Think of it as a UX problem, where you're integrating the OS app installer and launchers as UX elements. Remember that full UX constitutes environmental elements that are completely outside your control within any one app UI.

Is it always going to be the same set of customers going back and forth between both apps? Then it's probably best to add it as a feature to one app, so you can simplify the UX to minimize switching costs without depending on the OS.

Is it wholly different customers, or customers performing in unrelated contexts, where it makes more sense to have each feature set come with a different installer and app launch process? Then keep it separate apps, because in that case the OS switching costs don't exceed the screen real estate costs of adding more UI options.

In all these decisions, holistic user experience should come before marketing considerations.

Ted Neward

May 2nd, 2015

You dont differentiate between a mobile app or a web app, and that distinction can sometimes make a difference in the answers. In the case of a web app, cross-linking between web applications is pretty trivial, so its probably easier/better to build them as separate entities unless you have specific reasons to keep them unified--shared session state, unified login management, that sort of thing. Even then, its often possible to refactor the two back into one if the situation calls for it. (Or to do the reverse, quite honestly, though the URL management becomes trickier in those cases.) In the case of a mobile app, its a little bit harder to cross-link between the two. On Android, its much easier than on iOS, but either platform can make it work. This is where the discussion of how complementary/unified the two things (the existing app and the new feature) really are, and how unified you want the user experience to be, becomes more critical to the discussion. Id probably lean towards doing them separately (for versioning and reliability reasons if no other), but Id need to talk to you more deeply before I could make a solid recommendation. If its neither a web app nor a mobile app (in which case I can only assume its a desktop app), its almost certainly easier/better to keep them separate, since desktop applications have lots of ways to cross-pollinate/communicate between one another. Hope this helps.... Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526

Question stats