Is it beneficial to launch a complete app or gradually update the app over time?

Question

I have an application with a very limited range of functions. This means that once I have implemented all the features there will be almost no updates in the features. Users are aware of the range of features the application should have, so they might not be satisfied with the current state of the app. I have completed approx. 90% of the app's functionality and the development process will take at least two more weeks. What would be the better thing to do ? Launch a complete and full-featured application or roll out additional features in updates in the future ? These functions I am talking about are not essential, as the main functionality is already working. I assume it may be a better marketing strategy to update the app over the course of the next weeks as opposed to launch the full package. Does anybody have experience with this ? I would still prefer submitting the complete app, even though at this stage the users would be more than satisfied with the features.

Answer 1

This isn't a clear cut and dry question. There are advantages and disadvantages to each approach, and each should be used in different situations.

In apps for which there is little consequence of failure, it's usually best to release as soon as you have a minimum viable product. That gives you the chance to get real user feedback, which often shows that the features that you think are, aren't important to users. This early feedback is invaluable in many situations, and is why when in doubt I recommend releasing early and then rapidly iterating.

Few people will try an app again if their first experience was poor. So releasing early isn't about releasing a poor quality app. It's about releasing with a minimum feature set that is enough to make it useful / entertaining to your customers.

In mission critical apps (medical apps are an example), you need to release a fully functioning app that meets the design requirements. However these sort of apps are rare, and most developers will not be working on them.

Answer 2

In my experience, end users are surprisingly forgetful of missing features and limitations once the features are implemented and limitations are removed. Remember when smart-phones didn't offer cut-and-paste? Remember when the XBox One required a persistant internet connection?

But, again - my experience - users are less forgetful about code quality. It's hard to get past a program that "feels" buggy... even when those bugs are gone.

Answer 3

I think from a better marketing point of view, you should dish out the best features of your app at the first launch so that it can stand out among the similar apps. Then if it fares well (or not, it is a thing out of control at this moment), you can add any functionality that supports the main working flow. The app's faring in the market will significantly depend on how does it do at the launch time. Of course the better updates can change that later too but why leave things for future.

The baseline is - the main functionality should be complete and polished at launch and I agree with Alexey, get the user feedback as soon as you can by launching it at perfect moment than to wasting time by developing supportive functionality, you can add the supporting flows later on.

Answer 4

You can release beta version, it should be less stressful to the users when they face some problems. At least, beta status will forgive you. Also it's possible to involve limited set of users for beta-testing.

The point is the earlier you give your app to the real users the earlier you get feedback. You is not like your users, so I'd go with such strategy.

Release early, release often paradigm has its advantages. You users expect what the app should do, but they don't know how it would be.