This is the first in a series of posts about the app-making process. It’s about the app Mocle, which I had the privilege of designing and developing, and is currently in beta testing.
“It’s like Tinder meets Yelp,” Cassie said.
As an app developer, you hear a lot of pitches. Most these days are twists on, or mashups of, existing services (Uber for laundry!), so of course I wrinkled my face when I heard this. Cassie, a potential client, was explaining her idea on a rooftop bar. After she’d emailed me asking if I could develop an app, I’d given her two choices for meeting places: either over strong coffee at Stumptown or strong margaritas on a scenic roof overlooking the city. She’d picked margaritas.
Luckily, my obvious distress didn’t dissuade Cassie. As a VP at a nearby global asset management firm, she knows how to keep cool. She explained her eureka moment, which occurred when visiting Portugal. She and her female friends had booked the trip to without much planning. Without a good guidebook, or set itinerary, they didn’t have a clue where to spend their days and nights. A solution? Fire up Tinder, set the location to Porto, generously swipe right, and start asking the matched local gentlemen where to hang out. Tinder, in NYC and presumably in Portugal, is typically used for a quick date. But Cassie and her friends didn’t have the usual intentions. They simply wanted to know where handsome local dudes liked to spend an evening.
She envisioned a scrolling list of all locals – not just men or women – each of whom had picked their three favorite places. Users could see people near them, and message those users about their three spots. To join, users had to set their hometown and pick three nearby places. She sketched a few layouts in my notebook.
I’m not at liberty to say the proposed name for the app. Suffice to say that I frowned again. Whoops! From a prior career, I learned enough about trademarks to know that a made-up name is best. It doesn’t have to be trendy babyspeak, but at the very least, a matching domain name and Twitter handle should be readily available. I suggested that Cassie spend some more time thinking of a new one.
At this point, I was intrigued, and could see myself building her vision. However, two points of concern for me are always funding and milestones. Funding, in this instance, would be a small investment on her part. She would personally pay for a beta that was suitable to show investors. Something capable enough to have her friends and interested parties use. She’s savvy enough to know that marketing and scaling the architecture would require a larger investment, and more knowledge than my own. So, the stopping point would be that “100 person beta” as I imagined it. If investors jumped on board, we could come to another arrangement for future work.
After some more time discussing apps and future ideas, and a few more margaritas, we parted with the agreement that she’d send me some UI mockups and a new name. I could then put together a pitch for her.
Within a week, she responded with her preferences and some more sketches. Cursive fonts. Clean, flat, sharp design with a focus on good, round photos. Messaging like iMessage. And the name? Mocle. Rhymes with local. My local. Not in the dictionary, and Mocle.co and @MocleApp are both available. I did a test submission to the App Store and it didn’t bounce back with a “app name already taken” error.
I asked for a couple of weeks, and promised a Powerpoint presentation of mockups with a quote. No obligations.
At Pfizer, I often rapidly prototype an idea. While our mobile team has a whip-smart, talented UI/UX designer, sometimes she’s got a full plate and I only need to get a few screens on a device within days. While I could use Balsamiq or Photoshop to mock up screens, it’s faster to just open up Xcode, drop a few items into an interface, add some transitions and static data. If the app is greenlit, then I already have a head start on coding it.
Without a designer to help, and with only rudimentary knowledge of Photoshop, I went ahead with coding the interface. If Cassie didn’t like the mockups, or wanted to abandon the project, well… I’d have something nice for my portfolio. I’d be out about 20-30 hours of work. If she wanted them developed exactly as shown, then I had a jump on the project. In addition, the components I used – the buttons, lists, toolbars, etc., were all doable. Oftentimes, when I’m going off a designer’s wireframes, certain requirements are considerably more work than a non-developer might imagine. One example – I once worked on an app where superscripting the copyright symbols throughout took more time than any feature.
Another lesson from my day job – a professional, well-done slide deck can go a long way. My format is: screens on the left, text on the right, logos on top, and CONFIDENTIAL written underneath. In my opinion, the most important thing is that the images are actually shown on devices. A flat, borderless screenshot won’t have the same power. The closer that an image can look to the final product, the better. On each page, there was one aspect, along with add-ons. Cassie, having a background in pitching investors, would have a good idea what should be fully functional at a meeting and what would be superfluous. So, at the end of the document, I gave three configurations at three prices.
As for actual design, I went off what she’d sent, taking a few liberties but erring on the side of being conservative. I kept in mind a few principles. Signup should be as fast as possible, navigation often works best with tabs, and the content should shine. The icon I made was a simple, abstract rendering of eyewear with a shiny finish.
After a week of deep thought, shallow coding, and a few deep breaths, I fired off the document and scheduled a meeting for the following week to discuss next steps.
The second time I met Cassie was at the Ace Hotel’s lobby, a hip spot in the city for startup workers to meet. My opinion is that a pitch shouldn’t be in a standard coffee shop, or office. The app should be explained where it’ll be used. In this case, with a few drinks surrounded by coolness. I’ve found that a hotel lobby bar is a good spot for coding or meeting, because hotels are positive, bustling places brimming with people exchanging ideas and experiences.
After some small talk, and suspense from the client, Cassie revealed that she wanted the full set of features and loved the design. Success! She initialed all the pages, the price and payment structure (30% on project start, 70% on delivery of code), and left another mark on the pages. A few drops of her prosecco!
Truth be told, the actual coding of the app was pretty straightforward. I’d work on a screen or two, then send Cassie a Snapchat as a 5 second teaser. In a few places, we agreed to make some changes. We streamlined setup. For finding three local places, we switched from the Apple natural language search to the Google Places API, and back again, with a few adjustments to focus on user neighborhoods. We tweaked the data model in Parse, and routed messages through there as well.
Personally, the biggest challenge was push. While the push code isn’t hard to drop into an app, and configuration with Parse is easy enough, configuring an App ID, certificates, and provisioning profiles through the Apple Developer portal got hairy. And testing! I had to use two phones, with two copies of the app each, each copy signed with a different certificate tied to a different Parse app record. There had to be separate Facebook and Twitter keys for each environment. Finally, in order to properly test push, the phone in a few scenarios needs to be off. So, you can’t just run the app and view the log messages console in Xcode.
Now, at my day job I’d have people running test scripts. But with two phones running iOS 8, I can’t be sure what will happen on other devices. Sure enough, one device that Cassie wanted to install to was an iPad running iOS 7. Well, the push library had changed for iOS 8, and the different aspect ratio resulted in a chopped off button at the bottom of the screen. By this point, Cassie and I had a real rapport, but nevertheless, it was embarrassing to have a dud installation, and I took a couple of weeks to shore things up before showing her the next build.
In the end, push did end up seamless and reliable, and Cassie and her friends have been using it to chat. And I’ll never criticize another app for a dodgy push implementation!
Beta testing had initially been through old TestFlight. In early October, when Apple rolled out the new TestFlight distribution, we jumped at the chance to use it. In the process, I learned a few more lessons. First, I had to create a single, distinct email address for myself to administer the app in developer portal and iTunesConnect. In order to submit the beta build to TestFlight, I had to have my ducks in a row. And of course, the first submission was rejected because we didn’t pre-create the Apple tester a profile. Odd, considering that profile creation (from Twitter, Facebook, or from scratch) is a big part of the app!
After that was fixed, a day later we had a first beta! We soon found out that Apple’s TestFlight app only works in iOS 8. So, even though Mocle works in iOS 7, testers (mostly friends) couldn’t install the build without upgrading their phone. And there’s an odd glitch in that users can’t properly launch the TestFlight App from within non-Apple apps. So, trying to launch the TestFlight app from the Gmail didn’t work. Copying the link in the email to Safari and running it did.
And that bring us to the current day. For the past month, we’ve been using Slack to bounce ideas and files back and forth. There are a few minor tweaks and fixes needed, but in large part, the app is being seen and used by potential investors, only four months after work started. Pretty cool, considering that both Cassie and I have full-time demanding jobs!
I was extremely lucky to have a patient, trusting, fearless client, who always understood that the most important thing is that we get to beta. I can’t stress enough the value of just getting something out. While I have no control over where Mocle goes next, other than pitches for the next iteration, it’s a safe bet that Cassie is going to do big things.
You can find out more about Mocle at Mocle.co.