New to the site so sorry if this is the wrong section.

I'm starting app development and wondering what is the best practice when initially releasing my app. Do developers tend to keep some of the features for future updates to keep users active, or do they try to release the most complete app possible?

Basically, is it advised to release an app as soon as possible, and then periodically update it to the complete app you have in mind, or wait until you have it fully developed and release it with fewer update prospects?

EDIT: Thanks for the answers. I am currently just designing the app and writing down all the features I can think of and trying to prioritize which to include to the initial launch. Based on the answers given, I think I will get a MVP (thanks for the term) out as soon as it is ready, and then update with new features as soon as they are built. I am not holding back built features, was just torn between if I should build them all before launch or just the necessary ones, release, and then build the others.

As far as I am aware this isn't a clone. It is my first app though and I will be using it as a learning experience

  • 2
    There seems to be a bit of confusion. Do you mean that you have features that are already built and are holding them back? A lot of the answers seem to assume that you still have to build these feature and are delaying the release to build them. I think it sounds a bit more like the former than the latter. Aug 8, 2011 at 17:06
  • Are you creating a clone of another application?
    – JeffO
    Aug 8, 2011 at 18:14

5 Answers 5


Most people producing their first app (at least those who turn out to have a successful product) release what they call an MVP first.

MVP is Minimum Viable Product - the app at this point contains the bare minimum amount of features necessary to be a useful product.

Then, based on user/customer feedback, you can work on new features. The idea is, you'll only know what matters to your customers once people start using it. Some of the plans you had prior to launch may be thrown away entirely, or revised, in the light of the feedback you receive.


If you don't hold features back for later releases your application will never be released. There are almost always new features to add to software, but at some point you have to sit down and say "The application will release with X features and Y will come later"


No. Release the best product you can as soon as possible (where ASAP == marketed, tested, etc.). From there, use your time to continue working on new features. Your users will like the app more right from the get go and will spread the word. If you have more users, then you will have more feedback to build new functionality off of and more cash flow to fund the development.


This is going to vary from one app to another. If the app can be useful with just some of the functionality, then I'd say release it as soon as there is enough there to attract users.

For example, a Twitter client: It would be of some use as soon as you could read the feed and post updates. However, there's a lot of other features that could be added on later like uploading images or link shortening.

On the other end of the spectrum: a personal finance program (such as Quickbooks) isn't going to be of much use without a lot more in the initial release. You're going to need to manage multiple accounts, setup categories, validate transfers, etc.

However, I would not hold back on completed features. If you have some functionality that isn't quite ready for real world use, by all means leave it out.


There is nothing wrong with the business requirement saying "Feature X will be available by Y date". For whatever reason you want to "hold back" a particular feature, make sure the app is fully functional with out it. Otherwise, you're just going to be shooting yourself in the foot.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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