image
  • 07
  • January

How long does it take to create an app

Hi and welcome to this vblog. Today we are answering the question “how long does it take to develop an app”. This is a question all app developers get asked, along with how much does it cost, and those 2 questions are dreaded because they are very difficult to answer in the early stages.

But I’m going to give you that answer today.

The reasons why it’s difficult to predict the timing, is because it’s very much like asking the question “how long is a piece of string question” - my Dad used to say this to me all the time (in case you are wondering, the answer is from one end to the other).

You see apps are bespoke pieces of software, each different and individual. You get simple apps and complicated apps, some that use few functions AND some that use loads of functions, some that only display data - like a web page, some that use the camera, the GPS, social media integration and so on.

You really can’t predict timing until you know the detailed requirements. Only when you know the requirements in depth do you know how much work is involved. But research has been done, asking 100 developers this very question. The research has shown it takes on average 4.5 months to build the frontend app, and back-end infrastructure. Based on this and our own experiences, here are some ballpark timings:

  • 1-3 months for a simple app (like an Information based app that links to a database)
  • 3-6 months for a complex app (App with social media, in-app purchases, logins, favourite list etc.)
  • 6 months+ for a very complex app (multiple platforms, lots of functionality)

That said there are areas of the process to watch out for, where development can take far too much time, and become costly. Like with all projects without great planning and risk mitigation development can go ON and ON, resulting in a buggy low-quality app.

So here’s what WE do to ensure that doesn’t happen!

It all starts with the requirement gathering phase. If the requirements are noted down well, you have the opportunity to prevent misunderstanding and future problems. It forms the basis of the plan, and therefore the time estimation and costs. Poor requirements can lead to a bad plan, to developers making assumptions and getting it wrong. It can lead to more time in discussion and even the need to change or add functionality later in the development. Changes in the development results in changes after code is written, forcing developers to go back over their work, which has a large potential for introducing bugs.

Which brings me to the testing phase. With a thorough testing plan, we can test the beta app for problems right at the start and capture all problems early on. The ideal situation is to thoroughly test the app as soon as possible, and send detailed - organised feedback - to the developers. We want to avoid sending feedback regularly and sporadically. This makes it hard for the developers and might mean they have to make - minute changes regularly, thus introducing bugs. Also the better the testing at the start, the less likely it is for problems to be found later, leading to risky changes on a completed product.

Which leads me onto communication. Good communication between all parties will make the project run smoothly. It’s important to share the same vision, and avoid misunderstandings. As mentioned, a lot of this comes from the requirements capturing phase. Then there are the usual techniques of using the best format (email, videos calls, visits) and documenting and auditing.

With good project planning, including noting - risks and issues, we can track the development as it unfolds, and try to predict issues before they appear. Assigning extra resource, parallel working and integrating decision points,- are some of the ways we can reach deadlines. Omni App Studios uses the PRINCE2 planning methodology, to plan app development in a professional way. We also review projects for continued improvement.


For more information about what’s involved in creating an app feel free to contact me.

 

  •  
  •