Decision Chain For App Development

OR “What To Ask Before Putting Finger-tip To Keyboard”


For the purposes of this document, I’m going to use the term “App” to mean either “Game” or “App”.

App development is for me both a joy and a commercial venture.

At the moment, I try to develop Apps with the following goals in mind:

  • it should do one thing very well
  • the underlying complexity should be hidden completely from the purchaser
  • ideally, the purchaser should be able to use the App without needing to refer to the “how to” documentation
  • the documentation should be clear and concise and only one click away.

I sometimes develop an App strictly to play or to learn. Even when playing or learning, I usually have an end goal in mind, meaning that any code I write will be written in a manner than can be easily re-used and with the view to be used sometime in the near-to-medium future in an App.

Unless I’m developing strictly to play or to learn, and before I put finger-to-keyboard, I conduct research.

Steps to take before Starting to Build Your App

  1. You need to have an idea for an App that you wish to build.
  2. Are you almost-to-absolutely certain that you can build this App with the skills you possess?
  3. What plug-ins will you need (eg. geolocation, insomnia, inappbrowser etc)
  4. What plug-ins won’t you need (that is, make sure the complete list you made in 3 is absolutely necessary – don’t acquire more than you need – that’s called ‘bloating’).
  5. What development libraries will you need? Do you have permission and budget to use these libraries?
  6. What frameworks will you need? Do you have permission and budget to use these frameworks?
  7. Find out how many Apps do the same thing as the App you’re thinking of building
  8. Don’t despair if there are hundreds of Apps that do the thing your App is going to do
  9. Be mindful of the amount of competition your App will have never-the-less
  10. If the market is saturated, move on to your next idea. It can happen.
  11. If the market is saturated, and you want to deploy anyway, remember Homer Simpson’s logic on competition (taken entirely out of context):
    “But what about the victims? Hardworking designers like Calvin Klein, Gloria Vanderbilt or Antoine Bugle Boy? These are the people who saw an overcrowded marketplace and said, “Me too!”
  12. Even with your new-found, Homer-fuelled self-confidence, your App will always require a point-of-difference if it isn’t unique in the world. Make sure you have a point-of-difference.
  13. What are others selling their App for? (Your point-of-difference may be your price point by-the-way).
  14. Units – can you estimate how many units your App might sell? You should be able to find the largest seller in the space you’re competing in (in each store you’re thinking of selling in). You may also be able to calculate based on the size of the market place (eg. total Personal Trainers in my country equals X, and if I sell to a likely percentage of them, I’ll have sold Y units, at a price-point of P, given a total of $T, not including starting costs, App store margins and any API costs etc etc).
  15. Will you make a satisfactory amount of money according to what you found out from the previous point?
  16. Do you have the time required to build this App?
  17. Give yourself a reasonable deadline. You need to meet this deadline. Development is a discipline.
  18. What minimum features must your App have. Cut this list down as you code (you may run out of runway – there is always room for another release. Keep your customers hungry for more).
  19. Keep a note of features that didn’t make it into this release (it makes it easier to remember if you decide to come back to the App for the next release).
  20. Will your App idea be acceptable according to your understanding of all published App store policies and guidelines?
  21. Planning is ugly. Don’t forget to remember this point in order to get over it.

These are basically all of the points I can think of that make up my decision chain when I’m planning to build an App. Apart from that last test, if my App does not get built because it fails any one of the earlier tests I will document the idea and then park the idea. I will then move on to the next idea.

Keep in mind a “parked” App idea may get put back on to the agenda because of any number of reasons. Maybe a new framework, library or tool appears in the market that might make the App feasible now. Maybe a competitor retires from an otherwise profitable market place (it can happen). Maybe you can figure out how to deliver a unique point-of-difference. Maybe the competition isn’t as fierce as you first realised.

Maybe you simply found the time.

I do not let the last test in the decision chain get in the way of my resolve. That is why the final test is in that particular location in the decision chain. If I can’t resolve that final test and move on towards building the App, then there is a larger problem to deal with.

Do you have anything to add to this decision chain?