So you wanna build a mobile app?

Over the last several years I've had the opportunity to work with several startups as they develop their Minimum Viable Product, or MVP, in the form of a mobile application. I've been amazed by the number of ways a business can use a mobile app to solve a problem. From my experience, entrepreneurs typically start out with a novel idea that leads to a business idea that leads to an exploratory conversation with someone like me, a software architect, mobile developer, full-stack developer, etc... I love these conversations because I get the chance to experience this new idea from the perspective of someone that is excited about the possibilities that the idea offers.

What if it's the next big thing? What if it just takes off?

That excitement can be infectious and can lead to visions of grandeur. Unfortunately, that's where my part, that of a consultant and developer, comes in, but not in the form discouragement, instead in the form of filling out the picture of what it actually means to build a business around a mobile application. I've made it a policy, an ethical line in the sand, to never tell someone that came to me with a "big idea" that it was bad, because what the heck do I know, it could be the a stroke of genius and maybe I just don't get it. Instead I've assumed the role of helping them understand the different pieces of the typical mobile application so they can start to plan out what it will take to go from big idea to dollars-in-pocket.

In this article I'm going to describe the typical decision points and considerations for building a business around a mobile application.

Does it already exist?

It is a human reaction to get excited about an idea and assume it was born of your own mind, but, unfortunately, there are about 500 million other people just like you and me doing the same activity or interest on the weekends that could really benefit from a mobile application. In other words, there is a good chance someone else had the same idea. Because of this, the first place I usually start with a client is an internet and App store search to see if such an app already exists. This might seem rudimentary, but you would be amazed by how many people take the second, third, and fourth steps without taking this first step. And don't get me wrong: Just because it exists, doesn't mean you shouldn't do it. It just means you need to take those competitors into account, download their app, and learn from what they've already done before spending time and money on the project. This first step can save you time and give you inspiration for the project ahead.

Pictures are cheap, code is expensive

One of the most critical steps that I lead customers through is the prototyping phase. There are a plethora of Software-as-a-Service tools out there that can help you build a "kinda sorta" working version of your app without you having to learn a coding language or spend thousands of dollars on a designer or developer. These prototypes can have working pages, navigation, slide-out menus, lists of stuff, pictures, and a whole lot more, to really give a sense of how you want your app to function. Building a good prototype is also one of the things the entrepreneur that is looking to save money can and should do on their own, because it will allow them to get feedback on the concept from actual potential users before taking next steps. Yes, I can and will do this step, but if you leave it to me, it will just cost you more since developer time is expensive, and money is almost always an issue for entrepreneurs. Plus, sitting down and going screen by screen through your mobile app, deciding what it will actually do in fine detail, will cause you to think through parts of it that you wouldn't otherwise consider. This is work that has to be done, so you can either do it yourself or pay me to do it for you at $150/hr.

How will you sign people up?

Here's a shocker that most people building an app don't realize: If your app costs money as either an upfront fee or a monthly subscription, and you let someone download the app and sign up for your service through the application itself, you have the honor and privilege of paying Apple 30% of your revenue!!! This is an Apple policy, is not negotiable, and the developer doesn't see a penny of this money. I've worked with several entrepreneurs that had their financials all worked out until I dropped that little hurt bomb on them, only to hear cuss words and a diatribe about Apple and their terrible greed. I then get to explain to them that Apple built an entire ecosystem, defined a multi-billion dollar mobile app marketplace, wrote iOS, brought them customers through the app store, and we are all captive to this system. I've even had a few state, "This can't be!" and that their IT friend "Chad" says I'm full of it, only to do their own research and come back resigned to the fact that it's actually true, they're hosed, and Apple wins. But fear not, there are ways around this, I'll explain later.

Do you have a plan for marketing your app?

There are approximately a bazillion mobile apps in existence today covering every imaginable topic, so cutting through the crowd to find your potential customers can be a challenge. Yes, your app might be that one that goes viral because Oprah loves it, but that's a long shot, so you need to plan on marketing it and NOT relying on Oprah to say, "You get a mobile app, and you get a mobile app... everybody gets a mobile app!!!!!" The Oprah factor isn't a good business strategy. There are way too many approaches to marketing your new mobile app to cover in this article, so just know you'll need to save some dollars to get the word out when the time comes.

Which mobile platform(s) should you use?

I realize this is techie gobbledygook, but you need to consider whether your app needs to be built on native iOS and/or Android, or if it can leverage a Hybrid Mobile technology like Cordova/PhoneGap, Xamarin, or Appcelerator? The benefit of a Hybrid technology is you can write most of the codebase using a single set of technologies (HTML/CSS/JS) and deploy it to the iOS and Android stores without major changes. The answer to this question will be based on how demanding your application is on the native features of the phone, how responsive it needs to be in terms of UI smoothness, and whether or not your application must "feel" like a true iOS or Android application or if its "feel" can fall somewhere in the middle, meaning a blend of both iOS and Android. If your application MUST be native iOS and Android, you can assume the cost of building the mobile app portion of the project (as compared to any APIs or web stuff) will be roughly double the cost of building the same app using Hybrid technology. You also need to make sure if you choose hybrid, you use a developer experienced in hybrid technologies who can make the application perform up to your expectations. I would typically advise my clients to find existing applications that are hybrid and native to compare the performance and "feel" difference.

How much will maintenance cost?

Software is nothing like a fine wine, it does not age well. Because of this, you will need to factor into your business plan at least one major refresher a year, in addition to any planned enhancements, to bring your app up to snuff with any changes in the zillions of things that can and do change. This includes Apple or Google's policies, changes to the operating systems, changes to the frameworks your developer used to build the app, expiration of the SSL certificate used to make your APIs secure, and changes to the content to make your app look modern and not like last year's mobile app. For an example of this, consider when Apple changed iOS to use "Flat Design", making all pre-flat-design apps look instantly outdated. The result was that you either updated your app, or you looked archaic compared to your competitors.

How will you track your apps adoption and usage rates?

This is another item that many first time mobile app entrepreneurs forget to consider, but it is one that will have a major impact on your ability to respond to user behavior. Once your app gets into the Apple and Google stores and becomes live, how do you know if people are using it? How do you know if it is crashing? Both Apple and Android provide some level of reporting on things like installs and crashes, but getting the more detailed information like which pages users are going to requires some planning. There are systems like Google Analytics, Flurry, Amazon Mobile Analytics and many more that can help, but their usage must be baked into the application that you release BEFORE it goes to the store. These tools have gotten much better over the years and will be able to provide you valuable information, but your developer will need to know that you expect them to be in the app from the start. You'll also need to make sure your developer gets you login access to these systems from day one so you are watching and reacting from the beginning.

Will you require an admin portal?

Most of the time entrepreneurs conceiving of a mobile app focus only on the mobile app and forget about what it will take to administer and configure their mobile application. Nearly every mobile app I've ever built had a backend administration portal that allowed the owner of the system to view reports, configure the system, reset someone's password, and perform a myriad of other actions. This type of thing is often done in the form of a secured web application. The sophistication of the Admin Portal depends on the complexity of the mobile application, the data being manipulated, and the business logic required to support it. A complicated Admin Portal can add thousands of dollars to even the simplest mobile project and needs to be carefully considered. Once again, working through the Admin Portal's screens using a prototyping tool is an essential part of figuring out what you will actually need, and will save you money in development costs.

Will you require a Customer Portal?

Another thing that is often overlooked in mobile projects is the Customer Portal. The Customer Portal is the place a user of your mobile application might go to actually sign up and pay for your mobile application services.

Why not just sign up through the mobile app?

Remember that thing about Apple wanting 30% of your revenue if you let the user register and/or pay in the application itself? The customer portal is the way many mobile applications get around that cost by providing a web application their customers use to sign up and pay. This is a very common system requirement that typically involves integrating with a SaaS payment and recurring billing platform such as Stripe to allow for monthly subscription billing. It isn't a complicated part of your new system, but it will cost you around 20% of your total system development cost plus around 3% of your revenue for using Stripe. Once again, it is vital that you work through the general function of the Customer Portal using a prototyping tool so you and your developer know exactly what needs to be built.

What if I make the Admin Portal, Customer Portal, and Marketing website all the same web app?

This is one of the most common mistakes I encounter with startups. An entrepreneur has a limited budget and they go to a developer with their project and the developer says,

"Why build these things separately, I'll just make the marketing website and the two web applications all part of the same thing?"

The problem is that the Admin and Customer Portals will typically be built from scratch on something like Ruby on Rails, NodeJS, Java Spring, PHP, etc. The code for this type of project is mostly custom because the logic and data structures in your totally new system are mostly custom. Marketing Websites, on the other hand, are almost universally done using Wordpress, Drupal, Joomla, or something other industry standard Content Management System (CMS). This is because the needs of a marketing website, like SEO tools, Google Analytics, contact forms, nifty parallax background images, and WYSIWYG editors have become commoditized and therefore separated from custom application development. If you mash these two worlds together in the beginning, you will pay for it by having to come up with (or integrate) your own, custom solutions for the commoditized world of Content Management Systems. You'll also run into the peril of deploying marketing content changes to an application that, in some cases, might have to take an outage to do so. This is the same system providing the APIs on which your mobile application is dependent, thereby taking down your mobile application just to change some verbiage on your marketing website. Plus, Content Management Systems allow non-techies to make content changes, but if you mash them together you'll get to pay your developer to make those changes because it involved techie stuff like Git. Yikes!!! Do yourself a favor and keep those two worlds separate.

What are the ongoing costs?

Building the software is just part of the costs for a mobile application. Make sure to understand the ongoing costs of things like email integration through SendGrid (or other), platform (server) costs for AWS or Heroku, Apple's annual $99 developer license cost just to have an app in the App Store, storage costs if your app lets users store images on the server, and the cost of any other Software as a Service on which your application is dependent. These little charges can really add up when annualized and need to be part of your budget.

Where is the code?

One of the most important things to get straight with your developer from day one is who owns the code and where is it stored. This might seem obvious, but I have worked with entrepreneurs that literally had no idea where their previous developer had stored the code. I have had a number of experiences whereby (upon my taking over the project and code) the entrepreneur had a panic attack when they realized they didn't have the source code. The sudden realization of just how badly they had ended their relationship with the previous developer to which they still owe $1000 tends to cause unneeded stress on a Friday afternoon. Your code should be stored in YOUR GitHub account with you as the account owner and no one else.

What and when are the development milestones?

First time mobile app entrepreneurs often don't know what to expect from a software project, and that includes the schedule for delivery. They seem to all be under the impression that they say what they want, the developer gives a bid, goes way for two months to make their app, hands it over, and they're all done. This couldn't be farther from the truth, as a process like I described is the recipe for failure and crushed dreams. A critical success factor for an app development project is to have a routine (as in twice a week) checkpoint at which you get to see the progress being made, and to have your payments to the developer tied to milestones and dates. This does not mean you get to see a checklist showing what's been done, you get to see the actual work product, website, mobile app, etc. Software projects are typically done these days using the Agile methodology, by which software is developed and delivered in regularly scheduled small chunks to make sure that the project goals are in sync with what is being built.

Stay engaged or pay the price

The reality: There is no such thing as a simple mobile app. Go into a project with your eyes open, your budget thought through, and your wire-framing skills sharpened up. Stay engaged in all aspects of the project (especially the delivery schedule) from start to finish. Do that and you may survive it AND get to be the genius that came with the next big thing!