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/

Jarred Hardman

May 1st, 2015

If the new functionality provides value add to the current App, is something which will enhance your App, is something your Apps target market wants and you see it has generating additional revenue (from a captured market - its an easier sell to an existing client than acquiring a new one). But, if possible develop it as a module, which gives you the flexibility to convert it into a separate App once you have uptake from the users of your existing App.

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.

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 ;)

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.

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 .

Mike Rozlog Advisor at TechColumbus

May 1st, 2015

The starting questions are...

Does this totally new functionality have anything to do with the original app?
Is your first app priced to low?
Does it open new markets beyond the original app?
many other questions to help figure out the best approach

For #1, if it is totally new functionality that does not really relate to the existing app then a new app is the way to go. However, if the functionality is / would be expected as a feature in the existing app then you have to stay with that app and embrace and extend.

For #2, a lot of times when taking a product to market, people don't really do pricing models and when they do, they are overly optimistic about how sales will go and usually X% higher than what they actually turn out to be. This means that since sales are not strong enough to support the company additional money has to be raised, one way is to split functionality out and charge for each part and use the tag line that you pay only for the functionality you need not some full overpriced suite. However, most vendors after they get x number of functionality the combine and make a full product with a full price, it is just a stepping stone. If the price for the first app is too low, will adding the new functionality increase market adoption enough because you must have already figured out that people will not pay more for you app. Or, would it be better to release a new app to attract more people and have more exposure, thus a bigger market and hopefully increased sales for both apps.

For #3, this goes with #1 and #2... can you open new markets, if yes then build the new app. If it will extend your current market, the add to the current app and work on increasing market penetration.

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