Companies, from the size of the Fortune 500 to start-ups, use mobile apps to engage with customers, streamline their processes, deliver a service, or increasingly, as the backbone of their entire business. While there is currently a strong push for mobile first (or even mobile only) within the enterprise ecosystem, there are a few things to consider before you hire the developer or write the check.
Here are five things to consider before starting a mobile app project:
Identify your users: Is this app internal or external (meaning customers will see it)? Who are the people using the app and what are the demographics? Who will serve as the administrator who can add/remove users and data? If you don’t dig into this question, you could be wasting money building who you think your user is for and not who your actual target audience is. Don’t fall victim to this: early in the brainstorming process, bring all the key stakeholders together in one room for a discovery workshop to discuss the requirements and agree on the direction.
Research your competition – If you’re moving into a crowded space, creating a matrix of your competitors can go a long way in building your own app. Identify what you like and dislike about your apps, and why. Read their customer reviews and find out how users feel about the apps and what they are missing. Then see if that’s something you can capitalize on.
What problem does my app solve? Maybe you are building an extension of your ecommerce website on a mobile platform. Maybe you want to take advantage of the features a phone provides, such as location, push notifications, and site photos in a new way. But be warned: if your app isn’t going to enhance your existing business or present a unique interaction with users, take some time to consider the money and time you’re about to spend.
Native or Hybrid? For quick proofs of concept or simple data entry applications, a hybrid platform like Phonegap or Ionic might be the right choice. This option allows a development team to save time by only writing a code base that works for both iOS and Android. However, if you’re envisioning a more complex app, consider spending more time on native development, which means a different build for different iOS and Android operating systems. This allows the app to use the latest features of a native-only experience, such as Apple Pay, rich push notifications, Android Pay, and TouchID. All this allows the developer and the client to use the innovation that happens in our pockets and purses. Also, in general, native apps see better mobile behavior and research programs are more accepted by users. However, the difference in cost and time to market may be worth discussing.
Post Launch Plan: Ok, you’ve got a great idea and the plan is in place. What happens after launch? How will you collect and respond to user feedback? Who will make the changes for incremental releases: the original build team or someone internal? And keep in mind that mobile phones change frequently, with new features added every few months. An app is different because, unlike a website, you can’t make changes on the fly. Setting up a plan with a release schedule for adding features, making changes, and continually providing a reason for users to open your app will help you succeed once you release your new baby mobile into the wild.