Paul Gebheim on how to just get your mobile app out there

Paul Gebheim is a software engineer and mobile app developer at The Monkey Inferno, a personal incubator based in the SOMA district of San Francisco. The Monkey Inferno focuses on providing a creative environment where each member of the troop can dream up cool internet projects in the hopes of developing them into successful businesses. Previously, Paul processed terabytes of log data at Justin.TV, and kept tiny bits of information moving very fast for streaming database company, and spent way too much time worrying about how his source code was indented.

Paul Gebheim is a software engineer and mobile app developer at The Monkey Inferno, a personal incubator based in the SOMA district of San Francisco. The Monkey Inferno focuses on providing a creative environment where each member of the troop can dream up cool internet projects in the hopes of developing them into successful businesses.

Previously, Paul processed terabytes of log data at Justin.TV, and kept tiny bits of information moving very fast for streaming database company, and spent way too much time worrying about how his source code was indented.

API Economist: Congratulations on getting your new app launched, Beer Hunt. I see that it’s on the Apple App Store. Walk me through the Monkey Inferno creative process for the app.

Paul Gebheim: Basically, we are all old web developers. In order to help us think for mobile, our iPhone guy said, "I'm going to teach a class and show you all how to program iPhone apps." We all were like, "Sweet, it's going to be awesome," but we had to come up with ideas for what to make. One of the ideas that our sysadmin, Jesse House, came up with was about an app that lets you put pins on a map wherever you drink a beer. The more you drink beer, the faster you fill up the map. In two days, one of our architects, Michael, went from knowing nothing about how to make an iPhone app to creating the original app called, "Beer Map," now renamed, "Beer Hunt."

It took seven days to get the app in the App Store. Now the app sucked, don't get me wrong. It was basically a Google map with some pins on it and a database, but we put it in the App Store, and it started getting downloads. We started talking to people and we found that the app was resonating with them. That’s when we thought, “What can we do to make a real version of this product?”

What actually happened from there was our other sysadmin, Pete, who also was not a programmer, took the original Beer Hunt app and built it on top of Parse. It went from being a local app on your phone to one that is connected to the cloud as backend service. At the time I didn’t believe in it, but Parse is a wonderful example of a good API.

Using Parse in about a week and a half he was able to take this app, add Facebook integration, add geolocation, get lists of friends that were logged in, take pictures of the beer you’re drinking, and share your check-in with all your friends.

Being able to build without worrying about the backend half of the work, allowed Pete to show the rest of the team what was possible. This gave me a lot of energy to spearhead the part of building Beer Hunt that was hard for me, the product development. In this respect I was amazed by the power that Parse put into his hands, and I’d say it served us well up to this point.

API Economist: OK, so you’ve launched your app. Now what?

Paul Gebheim: We talk to people (users of the app). You can't make products that work without talking to people. Every “failure” is just a step towards creating the right thing. We have this app in the app store, and we know it's not good to some extent. We know that it doesn't work for Group A or Group B or Group C. But we are going to take that, and we're going to show people, and we're going to get information back from them. We're going to iterate as quickly as possible.

The way it works these days, with two people working on backend services, and one person doing app updates, we can iterate and get testable products in peoples hands really quickly.

There's this sheer speed of operations that the entire infrastructure of the web has given us. This reminds me of when I used to write Windows desktop apps and the amount of time that I would spend having to shove round pegs in square holes. These days, I still have to do some of that, but the ecosystem is such that it's rounder pegs in rounder holes.

API Economist: Sitting here inside your offices at Monkey Inferno, I’m thinking this might be the most creative work space I’ve ever seen. What exactly is the Monkey Inferno?

Paul Gebheim: Monkey Inferno is what we call an Idea Lab. We recently had some brand new people come and tell us that that was a good way to talk about it. We have 21 people, and we try to create as many projects as fast as we can. We're based around a six week development cycle where we try to create a product or a road map for a product in six weeks. We test it out with people and build as much of that as we need to in order to get feedback on it.

API Economist: Are most of the projects here at Monkey Inferno mobile apps?

Paul Gebheim: Not necessarily. We're doing more mobile now. It's the hot thing to do. We also had a couple of websites in the past, and in fact we run a big, old website called BirthdayAlarm.com. But, really, we're targeted at consumer web and consumer mobile. Birthday Alarm actually is an iPhone app now. The goal of Monkey Inferno is to be a playground for building cool consumer ideas. As part of that, we need to be able to be move quick enough that we don't miss out on an idea, but also build well enough that the idea is communicated to people so that we get an understanding of whether or not our product's going to work or not.

API Economist: If I say Paul Gebheim is a mobile app developer, what does that mean?

Paul Gebheim: It's actually complicated now because even my mother-in-law to some extent is a mobile app developer because she's a 53 year old woman who uses her iPhone all the time. I think the developer is not just the person that's sitting there writing the code. The developer is the person that also needs to use it, because there's a feedback loop in order to create something that works right. Everybody that participates in the usage of these things in some way is a developer, because they’re participating in the development process.

At the lowest level, most of us “mobile app developers” are just general programmers, designers, skilled technical people, who decided to try to use this really cool new form factor and the power that we have, either at our hand or in the cloud, to do interesting things.

Right now, some of the most interesting mobile app developers that I know are people that started programming two years ago. But they're able to plug stuff together now in such a way to make something that's cool and works, and support themselves.

API Economist: What are the preferred programming languages of mobile app developers?

Paul Gebheim: This is the other interesting part: everything now is mobile. There is a period of time where there was such a thing as not having a mobile presence, where you had a "I have a desktop website, and nobody views me from mobile." But now that's just not the case. Even if you have a website that really only looks good in Internet Explorer, something like 30-50 percent of the people are actually looking at it on an Android or iPhone browser.

The Beer Hunt App. Available on the App Store.

The Beer Hunt App. Available on the App Store.

Anybody that's creating content for the Web is creating content for mobile. All those same programming languages and stuff that applied to Web now apply to mobile, with the addition of, at least for iPhone, needing to learn Objective-C if you want to do native iPhone apps.

There's something interesting there because you're moving a group of people that have been used to programming with these really dynamic, simple languages like PHP, Python, Perl, and then moving them into a really rich complex thing, which is Objective-C, based on C. You could shoot yourself in the foot really easily.

The verbiage that they use to talk about things is really different. You have to switch people's mindsets as they move from making their website work a little better in mobile to creating really rich iPhone apps, for instance. On the iPhone there’s a lot user experience improvement with rich animations. There’s also different constraints because of memory and hardware limitations. Apple has done an excellent job of making their system easy enough to use that people can do very cool things very quickly.

API Economist: What makes a good API?

Paul Gebheim: Above all, consistency. There's a way that the good APIs that I interact with, once you've understood their own little language, just continue to “make sense”. Another way of putting this: I actually think of programming as writing poetry to some extent. It's poetry that's executable and creates an outcome. A good API reads like a self-consistent language. This ultimately means that most of the time your expectations of what a particular API is going to do closely resemble reality.

A really great example of this is the Twilio API. With the Twilio API, you're actually writing the stories. You're writing the scripts. At different points in the scripts, it asks your service, "Hey, what do you want to do next?" Since they structured it in that way, it allows for really natural creation of interactive applications. I can talk to somebody who doesn't know how to interact with Twilio, and the story they tell me looks like the story I'm writing. That's really important.

Another thing that's really important to me is being lightweight. A lot of this is because of the type of things I'm doing. Often, I'll have an idea at lunch, and I want to prototype it by 1:00 PM. Right around 12:30, I open up the API documentation. If I can look at it and understand the basic verb and actions at a glance, and it basically uses the same tools I'm used to, I can use cURL from the command line to call an API function or something. It's really easy for me to put it together.

If all of a sudden I need to install a large tool chain of things and I need to upgrade my XML parser or something, it just falls flat on its face. I will usually look for another option. There's a conflict to me between the way that the API feels to use and the power that is present there. Good APIs are very powerful, but feel very lightweight.

API Economist: You mentioned Twilio, I consistently hear it’s one of the best designed APIs out there. But what about an API that sucks?

Paul Gebheim: To your previous API Economist interview, PayPal's old API sucks. A lot of the reason that PayPal's old API sucks was because it just didn't feel like it grew with the times. It still very much feels today like it did when it was written. You have to do lots of random things to get information out of it. Error messages are presented in four different places in four different ways, and you have to combine all of them to understand what actually went wrong with a transaction. There's a lot of overhead in work involved in doing that.

Using that particular API, although it's simple enough that you can get a credit card transaction going in about an hour, it takes you weeks to get all the error cases right. They just don't present that information back to you in a way that's particularly easy to work with.

They also made a really big error, which was they didn't care about me as a programmer. Their heir sandbox environment is just so slow that it's almost unusable. For instance, we wrote a charity project called "Water Forward" to donate to a charity called "Charity Water." For this, we were processing credit card transactions with PayPal.

I had a suite of a couple hundred payment tasks because I wrote the payment system backend. Every API probably takes 60 seconds from their test environment. I actually end up having to turn off my tests to verify that my code was right in order just to get the test to run in a reasonable period of time. Stuff like that is a killer. It makes me just look for other options immediately.

Fortunately, the place that we're in now is that if you have an API for something, if you have a type of service, you're not the only one. Somebody else can give you access to a similar service, unless you're relying on Facebook. For every PayPal there’s a Stripe. In a world where there is options, you have to be good.

API Economist: Let’s get back to talking about beer. Why a beer app?

Paul Gebheim: I'm a craft beer nerd, but I'm not the type of nerd that needs to take tasting notes. I'm not a snob. I'm a nerd. I also have this experience where I'm from Wisconsin and I live in California. Two of my oldest friends now live in California. One lives in Texas, one lives in Colorado. A couple still live in Wisconsin. One of the things that used to bring us together was beer and our beer “nerdery.” When I heard of this beer map idea, the thing that popped for me was, "Finally, an excuse for me to talk to my friends."

I have a 20-month old son, and having young kids makes it really difficult to get out to your social networks again and start reaching out to people. But I just had an intuitive understanding that beer is something that is inherently social and that people will like. If you can take something that's inherently social and provide a new way for people to interact with it, I think that's going to be successful.

We decided, “Let's try to make a little bit more of a game out of this.” Beer doesn't need to be that serious. What happens if you just get rewarded for whatever you're doing? What if you can maybe compete with your friends upon drinking beer? What does it mean to compete with your friends on drinking beer? Is it just volume or not? What does it mean to be challenged in your drinking?

A lot of my past ten years of exploring the craft beer world has gone into this navigation of what it means to try new beers. How often do people try new beers? How often is it price that's a differentiator? There are so many little things like this. We've tried to build that into how we're scoring this game.

API Economist: What advice would you give to aspiring mobile app developers?

Paul Gebheim: Don't wait to show people. That is the biggest piece of advice. Mobile apps are so cheap and easy to make any idea you have has already been had, for the most part. The differentiator between what works and what doesn't is the execution of what parts resonating with people, and the ability to build a community. If you have an idea and you can code it up quickly, don't think about the scale at first. Don't think about perfection, think about what you can quickly learn.

The creative space that is Monkey Inferno's office in San Francisco's SoMa district.

The creative space that is Monkey Inferno's office in San Francisco's SoMa district.

If you're ever sitting there working on your app in your own little vacuum for three months, and you realize that you don't actually know why you're doing X, Y, or Z, you need to stand up, put the current build on your phone bugs and all and you need to walk to a bar and hand it to somebody.

The beauty of building an app you can show someone in a bar, is that you should be able to get feedback right away. It's of the utmost importance, because if what you're working on right now isn't working, there are a trillion other ideas that might. There’s nothing worse than building a perfect product that no one needed.

API Economist: What are your favorite mobile devices that you use, and what are your favorite apps?

Paul Gebheim: My favorite mobile device is actually my iPhone. I also am really interested in all these new personal life tracking devices. For instance, the Fitbit, or the Nike FuelBand. There's this amazing effect of having this technology be really cheap and easy to make. It makes it so that now you're able to collect lots of cool information about yourself. I use the Nike running app to track my runs, and it's made me a better runner. It’s the “quantified self” movement and it’s awesome. What can be measured can be changed.

This brings up one of my favorite apps. It's called "Moves." It uses the accelerometer and the GPS in the phone and maps your movements. There's just something interesting about looking at that. There was an “aha” moment when I realized that it took nine minutes to walk from Bart to work, but only four minutes to skateboard. I thought, “That's eight minutes a day!” Eight minutes a day matters to some extent.

I also love "Fancy Hands," which is a service and app that gives you access to a fleet of personal assistants. This is another case of saving 8 minutes a day, since they can efficiently do tasks and get my feedback from their iPhone app. Using them I’ve sent flowers while a plane was taxiing on the runway, and processed a mattress warranty while giving a Beer Hunt presentation.

API Economist: Paul, thanks for inviting the API Economist into the Monkey Inferno!

Paul Gebheim: My pleasure! Thanks for coming.