The following cautionary tale of the times is based on a recent factual occurrence. Lessons learned, as relayed to me by the protagonist, are included. Names have been changed to protect confidences.
Once upon a time, a small business owner named Karinne wanted to create a mobile app based on her consulting and training tools. Her methods and tools had brought her great success. In fact, she had published a successful book about them. Her business was booming, and she wished to capitalize on the growing market for mobile apps.
Karinne looked around for a skilled, experienced and reliable app developer, and was alarmed to discover they are quite difficult to find. Luckily, her neighbor Cody, who worked as a software engineer for a large telecom company, offered to help her out. Karinne was grateful.
Cody told Karinne that he had his own dreams of going independent as a mobile app developer one day because he saw a great opportunity for self-employed people to promote themselves through apps. Cody then asked Karinne if she wanted to be his “guinea pig.” Karinne said yes.
Lesson #1: Do not be a guinea pig.
Karinne wrote content and designed the interactive utilities and functions, and Cody went to work programming. Alas, Cody was slowing down because the large company for whom he worked had just implemented a massive reorganization. Knowing that the online app store would not let her reserve a name for an app until it was submitted, Karinne became worried that the name she had selected might get snapped up before Cody was able to complete his development.
Karinne expressed her concern to Cody, which he took to mean that he should submit it immediately for approval, irrespective of its current state of under-development—i.e. without a truly workable utility—to protect the name. Karinne had no idea that Cody had done this. A few weeks later, she happened to search for the name of her app in the online store, and was surprised to see that her app was live. She was frankly shocked that the online store owner had approved it.
Lesson #2: Do not rely on the app retailer to perform quality assurance.
Karinne asked Cody how quickly he could finish the app and submit the update so that it would be the high-quality app she had designed. Sadly, Cody told Karinne that he couldn’t possibly get to it for another three weeks due to all the shuffling going on at this company. Karinne was at a loss as to whether or not she should have Cody take the app down. She finally decided to leave it up and simply hope that no one searched for the app before she got the workable app live.
Lesson #3: Hope is not a substitute for a sound business decision.
Much to Karinne’s glee and dismay, nearly 500 people had downloaded the app in the first week, resulting in two scathing reviews. Now, Karinne had a real dilemma, because scathing reviews were harmful to her product and brand. Karinne asked Cody if he might be able to hurry up and finish the app and post an update. Cody told Karinne that everyone always gets a few bad reviews, and that she was confusing a bad review for an app with a personal indictment of her and her tools.
Lesson #4: Engineers aren't always the most savvy marketers (and vice versa).
Karinne decide she must find another developer. She found another programmer, Tab, through her network. Tab was a young but savvy programmer. He hadn’t actually developed a mobile app, but he told Karinne he loved learning and that he had been studying the app world. Tab wanted to finish the app for Karinne, telling her that since he already knew a similar language, it wouldn’t take much to learn mobile programming.
Lesson #5: See Lesson #1. (Karinne admits she can be a slow learner.)
At this point, Karinne decided to call the app retailer, a big computer hardware, software, and mobile device maker in Silicon valley, to ask if she could switch developers. Karinne received expert service and advice. Unfortunately, she was told to never ever submit a business app under another developer’s license because they were only transferring app ownership in very limited cases.
Karinne had no option other than but to ask Cody to remove the app from the online app store. She then set up a developer’s license under her own company’s name so that she could use any developer she chose. Now Tab could help her.
Tab eagerly set up an overly aggressive schedule, and proceeded to miss commitment after commitment. Karinne grew worried yet again. To make what could be another four or five more paragraphs of story short, Tab made a fatal mistake in programming: he made the entire app in C++ instead of Objective-C, and subsequently threw in the towel.
Fortunately for Karinne, she did not pay either Cody or Tab a dime.
Lesson #6: You get what you pay for.
There is a happy ending to the story. Karinne finally started from scratch, did her due diligence and held out for a reputable development studio with a track record of successful mobile apps. It seems like the obvious thing to have done in the first place, but then, hindsight is always 20-20.
Be careful out there, all you aspiring app owners!
Matthew E. May is a design and innovation strategist. You can follow him on Twitter here.
On the go? Find this and other OPEN Forum articles through your mobile phone or Blackberry® or through the new OPEN Forum App for iPhone® from American Express. Visit openforum.com/mobile.