What are the on-going maintenance costs of agile app development?


We have been populated the team, have our backlog, and have completed a sprint with all its meetings, but we aren’t done, we only have an MVP. As discussed in the first part of this series, agile is never done. This is done to, somewhat counter-intuitively, save money and time. When you are hatching a plan to develop an app, there is basically no way to really know how the app will be used by users the most. The objective on any app is to generate users which then generate money from some means. Therefore, it s partitive your efforts stay keenly focused on the users and make sure their experience is not only great, but gets better and better.


This fact of the industry today has the term “on-going” maintenance somewhat of a misnomer. Yes, you will need to update when Apple, Google, or any other 3rd party updates and renders part of your app incapacitated, but “on-going maintenance” is much more than that, it is updating the app to do much more. The second you give the very first version of your app out, or even talk about it to colleges or friends & family, you will hear opinions. Some business leaders feel they just need to develop an app and that will miraculously bring in money. Yes, they will come to your app, but they won’t necessarily be back unless they are very committed to it, due to your band or other factors. The best apps get a wide audience within their given market. This not only gets those loyal users, but also brings in other more reluctant users.

The way this is accomplished is by keeping the agile development cycle moving. The backlog acts as that priority list with bugs, requests from users, and anything else that needs developed. This ends up filtering only the most important items to the top and being developed at any given time. It also gives great clarity into the future, something not possible in the traditional waterfall method of development. So, at any given moment, only the most important things are being developed and that definitely means the users will be highly engaged, their experience is always getting better. There is also a side-benefit of this development tactic of agile cycles.

One often overlooked aspect of owning an app is keeping it top of mind for users with it on their phone. Notifications can easily annoy people, but if you are on an agile cycle, your app will update on devices that have automatic updates turned on (most devices) and even if they don’t they will be prompted, by Apple or Google to update the app, reminding people of the app and gaining intrigue about what new features are in the app. This updating is an expected and comforting task, but with waterfall methods, you would have to wait every 3-4 months at least to get an update, whereas with agile, you are gaining this benefit every 1-2 weeks!

Keeping with an agile cycle and iterating every 1-2 weeks will go a long way to dealing with the issue of on-going maintenance that you probably came in thinking about. On top of this, it is bringing real value that will get more user engagement which is the name of the game in app ownership. With this added engagement, your app is set to compete with anyone and all you need to do is find a team that can help you make it happen.