As an entrepreneur focusing on technology companies I have found myself encountering some issues with developing and releasing mobile applications that I think are worth pointing out in case there are others that are about to embark on their first attempt.  For most businesses it’s not a matter of IF you will need a mobile application but more WHEN you will need one.  As we all know, mobile devices are used in just about every aspect of life now almost to the point of being a constant distraction.  Given that, most businesses will eventually have to accept that and find a way to reach their customers/clients pretty much 24×7.

1. The first challenge comes with ideation (aka coming up with the functionality your customers/users want).  It’s often tempting to fall on either side of this and either produce a mobile application that is a watered down version of your services OR providing so much functionality that the mobile app is overwhelming and just too cumbersome to use.  In most cases, less is more but thinking through the functionality you might add in advance can save you a ton of time and money when you start developing the application.  Most businesses spend way too little time on this step which results in tons of rewrites, missed delivery dates, and budget over-runs (been there, done that).  I highly recommend writing functional specifications and running those by as many friends and potential users as you can before writing a line of code.
2. The next issue you will face if you are not a developer or don’t have mobile developers on staff is finding the right company to make the application for you.  Keep in mind that no matter how nice the salesperson is that you talk to this is work for hire and in general they are going to tell you what you want to hear.  You can expect a minimum of 25% on top of any quote they provide in both time and cost (and that is a best case scenario).  Your best bet here is to focus on those that seem to best comprehend what your app is going to do and seem to be able to take your functional specifications and turn them into technical proposals.  Do not hire any developer before they have provided a detailed proposal that meets all of your functional needs and make sure that is a part of any contract you sign with them (be thorough here because I promise you it will come up again and again before you are done).
3. Another facet of development that is often overlooked is the development platform.  Keep in mind that the initial development is just that, you are going to have to add to and maintain this application over time so don’t pick a developer that uses a niche mobile platform that nobody else is using.  You also have to decide if you are going to write native applications that target iOS and Android or if you want to use something that is write once and run on multiple devices like a Phonegap-based platform.  In general, you will sacrifice some usability if you choose Phonegap but the usability will be consistent across all platforms and the cost of development will be considerably less.  Lately most apps I have released use either Telerik (specifically their Phonegap platform) or NSBasic (also Phonegap based).
4. Most mobile applications are going to heavily leverage jQuery, HTML5, and CSS.  If those things aren’t familiar to you then the most important thing to know about them is that you are going to want to spend a considerable amount of time planning out the design and invest in a great user-interface designer that can provide the markup that your developers are going to need (in some cases the developer will take care of this as well, but usually not as well as a design expert).  It’s really important to follow generally accepted practices here because mobile users are exceptionally fickle and very used to certain designs (think FaceBook, Twitter, Instagram, Vine, etc.).  Find a popular application in the app stores that is fairly close to what you are going to be doing and use that as a baseline (if the reviews are great).
5. Once the project starts get frequent status updates because there is literally no other way to make sure you stay as close as possible to your delivery timeline and/or budget.  I don’t care if a developer tells you they ALWAYS hit their deadlines and they don’t need you pushing them.  It’s usually the case that they meet their second, third, or fourth deadline and not the first one (don’t worry they will always blame any slips on scope creep – AKA you adding more requirements).  It’s also important to provide feedback as quickly as possible so that if the developer starts going in a direction you don’t like you limit the amount of rewriting they have to do.  If a developer fights you on this early on I would highly recommend cutting your losses and moving to a different developer.
6. Another very common mistake is not entering into a contract with the developer before the actual development starts.  This is absolutely an insane thing to do that will definitely come back to haunt you.  You should of first had them sign an NDA (non-disclosure agreement) before even talking to them.  You need a contract that fully references your requirements and their delivery dates plus you absolutely must make sure they assign all of the rights exclusively to you for anything that is developed.  This is a non-negotiable requirement and don’t settle for anything other than fully exclusive rights to the app.  I have had developers fight me on this before and frankly I will walk away from their deal in a heartbeat and you should too.
7. As development continues and you are monitoring progress daily or weekly at a minimum, you will want to make sure that you are testing on the target platforms as early as a prototype is possible.  In most cases now we stub out the full application first and run it on the target platforms.  So basically design all of the screens without the functionality and just flip through all of them to get a feel for how the application is going to flow in its final form.  Once the underlying code is developed it will be much harder, time consuming, and expensive to make changes to the basic flow.  This is another step that I would never skip again going forward.  Plus, it gives you something to use in pitch meetings for employees, advertisers, partners, or investors as needed.
8. Resist the urge to keep adding requirements as much as possible (this will give the developer all he or she needs to justify any missed deadlines or budget over-runs).  If you did a good job of defining the functional requirements upfront you should make sure those are taken care of first and recognize that YOU are not your customer/user.  In the end there are always going to need to be changes made after the application is launched and you adding just one more thing is probably not going to be the difference between a successful application launch and a poor launch.  With that said, that is exactly how you should look at each change.  How critical is this to the success of the application?  If it is not absolutely critical, don’t waste development time on it.
9. Knowing when to move from prototype to alpha/beta testing is also important.  You need to line up a good group of testers that will help you move the application from the prototype stage all the way through to a release candidate.  Try your best to pick a broad group of testers with at least one person that is fairly picky and well known for hating everything new they try.  If you just have a bunch of yes testers/people involved you probably aren’t going to hear the feedback you really need to hear.  The biggest issue here is often letting this stage take too long as you try to make the application “perfect.”  There is no such thing as a “perfect” application.  You will need to make some changes to accommodate actual user requests so get comfortable that your functional requirements work well and prepare to release the app.
10. Spend a lot of time at least a month before the expected release date getting your accounts setup with both iTunes and the Google Play store.  You will find that Apple is way slower at approving everything from your initial account to each and every version release (so plan that into your timelines).  You also want to be certain that you collect all of the requirements in advance including your app descriptions, screenshots, and everything that you will need to submit your application for review.  The Google Play store process couldn’t be faster you can easily turn everything around the same day for literally everything.  Apple will have you wanting to pull out whatever hair you have left on your head after going through this whole process.  Given that pretty much everything with Apple takes 7 to 10 working days the last thing you want to do is miss something simple that resets your place in their review queue.  NOTE: every update to the app binary with Apple also does reset their review queue so be sure the binary you submit the first time is good enough to be released (any updates will also take 7 to 10 days to get approved).

The initial release is most likely just the beginning or your mobile application experience.  You are going to need to maintain the application and most likely provide fairly frequent updates to add more and more functionality based on user feedback (this is a major factor in determining how many users delete your app – lack of updates).  Consider this when you are choosing the development platform and resources.  If you are a developer like me then make sure you can take over where the other developer has left off or have a good maintenance agreement prepared in advance with someone (if possible).  You have to be sure you know out of the gate what it is going to take to be able to maintain a good mobile application for your customers/users.  If you have any questions on mobile application development and release (not project work, just the process or general feedback), hit me up on Cyber Dust username KenneyMyers or on Twitter @KenneyMyers.