How much does it cost to build an app? How long does it take to build an app? Well, it depends on several factors. Apps can be built for as little as a couple of thousand to dollars, or as much as hundreds of thousands of dollars. It all depends on what you want your app to accomplish. We have a created a framework to help you think through your app in some very concrete terms, which can help determine the cost and time to required to build the app.
We look at this framework as the building blocks for an app. Like with any structure, building it requires setting a strong foundation. This requires having a good grasp of the platform(s) on which you'd like the app to be developed, knowing your localization and internationalization strategy, not leaving security to be an after thought, and having a good sense of which APIs - both internal and external - your app needs to integrate with. Once the foundation has been set you can move to building the core of your application. This involves having at least a feature level grasp of what your application will do. Finally, to maximize the value delivered by your app, you need to understand and implement your apps reporting & administrative needs and how you plan to support the app once it hits production. Let's take a closer look at each of these areas.
Platform: Knowing which platforms your app needs to be built on is of paramount importance. The wrong decision here can mean the difference between a great app, and one that delivers extremely poor performance and generates little or even negative interest. Some of the key considerations here include:
- iOS vs. Android vs. Others: This might seem like a pretty simple decision at first, but based on the demographic and region of the world you are targeting, going iOS first or Android first, is not a given. We were helping scope an app targeted towards the lower income market in the emerging world for which a simple text message based service made more sense than an extensive app. On the other hand for some apps to gain maximum virality you might have to go cross-platform from the get-go.
- Native vs. mobile web - A few years ago HTML5 was all the rage. Today developers have begun to recognize the limitations of HTML5, and the pendulum has swung the other way. The right decision here though is not whats in vogue, but what makes sense for your app - perhaps the limitations of HTML5 are not an impediment for your app.
- Develop native vs. using a mobile application development platform (MADP) - We will cover this top in a more in-depth manner in a future post, but at a minimum you need to know what the advantages of developing using a MADP platform vs. developing a native app are and why your development team is recommending one over the other. The comparison is usually made between the cost advantages of MADPs vs. the performance advantages of native, however in reality the comparison is rarely that straight forward.
Localization: This aspect of app development is usually not given much thought, and perhaps is as simple as starting off as an English-only app that needs to be deployed in the iTunes app store. However, what if you were an international airline carrier with passengers from all over the world? Suddenly, a seemingly simple decision requires at least some analysis to know which languages your apps needs to support and which countries app stores the app needs to be made available in.
Security: Like with localization, security is too often an after thought. Some very popular apps have taken security lightly and have seen it come back to bite them. Recently the Starbucks app, the most used mobile payments app in the US, was caught up in an embarrassing security breach when it was revealed that it was storing its customers' username, email address, and password in clear text on their mobile phone. Our recommendation is to not take security for granted from the get-go. Do not assume that your app developer will build your app to meet best practice security requirements. Be explicit about the security requirements you expect - particularly as it relates to encryption, authentication, and authentication information retrieval policies. You at least owe this much to your prospective users.
APIs: Today APIs are available for a variety of different popular external B2C applications in particular Facebook, Twitter, LinkedIn, etc., as well as B2B applications such as Salesforce. At a minimum, we recommend that project owners know which applications they need to access through their app and the feature(s) they expect to be able to provide to the end-user by enabling said access. "I'd like my application to connect to LinkedIn" is usually not very informative. "I'd like my application to connect to LinkedIn to be able to auto populate x, y, and z user profile fields" is a lot more useful.
Features: Most of the better development teams today either completely or partially adhere to the agile development philosophy. In agile development, the primary unit of work at the team level moves away from a discussion of requirements to a discussion of user stories. These user stories are generally developed in conjunction with the development team and are too granular to invest too much time in up front. Our recommendation here is for you as the project owner to think one level up - at the level of features.
So what is the difference between a feature and a user story? Let's take the example of a recent that app we helped facilitate the development of that helps you find things to do based on your mood and your location. The ability to determine your location is a feature. However, your location can be determined based on your current coordinates, some future coordinates, or the neighborhood that you live or work in - each of these comprises a different user story. Knowing what can and cannot be done at the user-story level generally requires the guidance of the development team, and is best left to be determined in conjunction with the team.
Reporting: Why is reporting important? Shouldn't I be able to capture stats via the number of downloads and the rating that my app has received directly from the app store? That is correct, but that is not really enough information to determine what features within your app are being used, or in what conditions your app crashes, or how long it has been since a specific user has logged into your app, etc. Usually developing your app is just the first step towards attaining a greater goal, and it is impossible to predict whether or not you are making headway towards that greater goal without some deeper insight into how your users are using an app. We highly recommend thinking about what user activities and experiences you'd like to keep track of and accounting for those capabilities when developing your app. Again, like with security, don't take for granted that your development team has a good sense of what those capabilities need to be - it's your app, and you need to take ownership of it. These days, integrating reporting capabilities - even advanced ones - into your app usually doesn't require a ton of additional development effort, but it does require identifying and integrating with the right reporting tools made available by external providers (e.g., Flurry, App Annie, Google Analytics). Knowing which reporting tool to integrate with to deliver which capability is something you should defer to the development team on, but knowing which reporting capability is required in the first place is your responsibility as the project owner.
Admin: There are very few apps that require no administrative capabilities. Below are some common examples of admin capabilities that apps require:
- Roles administration: Not all users are created equal. Some users might be considered super users and require special privileges associated to a role that they perform on your app - for example adding new stores or restaurants to a curated recommendation app.
- Content administration: Your app might be dealing with content submission from your users and you might want to feature or highlight certain pieces of content more than others. This might require content curation capabilities that need to be provided to you as a superuser, but not to every user.
- Security administration: You might want to be able to change the security policies related to your app, for example the password strength requirements or how often passwords are set to expire. You might want to lock down certain users from your app until certain verification steps are complete.
When working with an experienced development team, one of the first things they are likely to do is build user personas that are related to different user stories. This should help define the specific actions that you'd like different types of users, including admin users, to be able to perform. However, at a minimum we suggest giving some though to what constitutes an admin user and what features the admin user should be able to control.
Support: Apps don't upgrade themselves, and just because an app works close to perfectly in the beginning, it doesn't mean it will continue to do so into eternity. Apps can break for a variety of reasons ranging from OS upgrades, to API changes, to experiencing a heavier load than they have been tested against. All of these problems can generally be fixed, but not if you don't have the right support mechanism in place to help you. Most teams that develop an app might give you a 2-week or one month warranty window where they will support the app for break-fix type issues, but often you might need support for a longer than a month on app. Additionally, it is critical to know the different between break-fix and a new change. Adding a new capability to an app is not a break-fix issue, in technical terms it is considered a change request, and - depending on the complexity of the app - a change request can be more complex and expensive than developing the app itself.
In summary, there are lots of things to consider when you go down the path of developing an app. Maybe your app is a use and discard marketing app for which many of the above considerations are an overkill, but even if that is the case it makes more sense to start with a more holistic framework like this and eliminate what you don't need, vs. start something bare and then realize two months into the project that there were several aspects of the app that had not been thought through. Spending and extra week or two researching some of the capabilities that your app needs to support is not a waste of time when you consider that not having those capabilities can easily cost you an extra couple of months or, in the worst case, your reputation.