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.

4 Answers 4


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.

  • What is "little consequence of failure" to you ? I want my app to be successful, a bad start would hamper growth rate, therefore it is a kind of failure and I would have to bear with the consequences. As a first time submitter I am not sure what these consequences may be (negative : drop in sales, bad reviews, unsteady growth -- positive: more media attention, word of mouth).
    – the_critic
    Commented Jul 5, 2013 at 12:27
  • @MartinE. "little consequence of failure" refers to catastrophic consequences. Like someone dying, or an industrial disaster. Not about whether your business is successful or not.
    – JohnGB
    Commented Jul 6, 2013 at 2:22

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.

  • So, I guess I'm just agreeing with @JonGB. ;)
    – Don Nickel
    Commented Jul 5, 2013 at 12:08

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.

  • Yeah I agree, but is it not important to make a perfect first impression ? I want it to be the non-plus-ultra in this area, so when I update it irregularly wouldn't that let it fall under the table ?
    – the_critic
    Commented Jul 5, 2013 at 10:43
  • Yeah but when a possible user wants to have a go at an app for a known functionality to fulfill his 'requirements', he'd expect to have that working flawlessly in it. If it provides other functionalities, it is bonus. So from that point of view, if your app is ready with main functionality, you can have a go with it and can keep updating it with the 'Bonuses' :)
    – Zen
    Commented Jul 5, 2013 at 10:56
  • Perfect first impression is something subjective, to convince the users it should be enough to give them better experience (which could be measured with usability metrics). Commented Jul 5, 2013 at 11:06

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.

  • The problem is, my user base is familiar with what the app should be doing, so a beta is out of the question. I was asking because it took a long time to develop the app and I finally want to submit it. But there just always seems to be something that needs improvement, so I have to make a decision...
    – the_critic
    Commented Jul 5, 2013 at 10:33
  • @MartinE. – I've updated the answer. Commented Jul 5, 2013 at 10:50
  • Well I am not quite sure about the "Release early, release often" paradigm. While open-source and free applications may benefit from it, I think paying customers will expect to get value for their spendings.
    – the_critic
    Commented Jul 5, 2013 at 12:29
  • Okay, @MartinE., how do you decide the app is polished perfectly and ready for usage? It is either your subjective (possibly biased, erroneous) decision or real user feedback. I do not tell to release raw product, just first version. By the way, pricing strategy could be very flexible. Commented Jul 5, 2013 at 13:17
  • No it is not subjective. I have reference values from my competition in terms of functionality. I have to enter strong in order to stay strong. So my decision is that I will submit an entirely complete application.
    – the_critic
    Commented Jul 5, 2013 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.