Table of content
- Starting at Baruch MFE
- The Birth of an App Idea
- App-lying Myself
- Time to Submit the App
- Marketing the App Free-style
Part 1 - Starting at Baruch MFEOne day in July 2005 I called Dan Stefanica, director of the financial engineering program at Baruch College. I had been to one of the open house sessions and heard that they had a somewhat new and pretty good program there. My econometrics professor had suggested I check it out.
To my surprise, Dan picked up. I was expecting a machine; or at best a receptionist. So I wasn’t exactly prepared for a conversation. I said, “I went to the open house the other day and have an application in progress.”
“So you want to meet with me or sit in on a class?”
“When can you meet.”
“How about at five o’clock?” (It was around two.)
When I hung up, I started getting a little nervous, which is not like me. I was totally unprepared and not confident at all about my skills. I was a graduate student in economics at City College and had recently finished two courses in econometrics. Before that, it had been many years since my calculus and statistics courses as an economics undergrad at UCLA. And I’d gone nowhere near something like stochastic calculus.
At five I arrived at Dan’s office and he skimmed through my application and asked me a few questions. Then he said (and I paraphrase) “I don’t think you will make it in this program.” Nice. In my mind I totally agreed, but I’ve never been one to believe people when they tell me I can’t do something. I prefer to find out myself.
In the end though, Dan told me to take the calculus “refresher” course (3 semesters of calculus crammed into two weeks) and then see if I still wanted to apply. I got the calculus book and did the first 12 chapters before the class started. I did good enough that Dan allowed me to be in the program “provisionally” by taking Introduction to Pricing Financial Instruments, a class taught by Dan. If I did well, then I could stay. I did well (enough) and so I stayed.
I graduated in December of 2008 with my Masters Degree in Financial Engineering, having attended courses part-time while working full-time at an energy trading software firm. There probably wasn’t a worse time to graduate with such a degree. My original plan was to look for work, then change jobs to one of the big banks. That plan changed to “keep your job until further notice.” Further notice came in August 2009 when I was laid off.
One week after my last day at the office, I took off on a cross-country road trip. I visited numerous national parks along the way, took a lot of pictures, visited some friends in California, and generally chilled. The rest of the year went by fast. I went out a lot, visited family a lot, and had a trip to Mexico. Luckily I had save up enough money over the previous five years (and did well in some key stocks) so I didn’t need to rush out to find work. But work would find me soon enough.
Part 2 - The Birth of an App IdeaOne day Ernesto and I were sitting in Shade, a small Greenwich Village bar with great crepes, drinking our third or fourth Weihenstephaner Hefeweissbier, talking about how we should be developing iPhone apps. Ernesto Santos is an experienced, self-employed Web programmer. However, he is most identifiable as the president of La Boule New York, a petanque club (labouleny.com). Shade is where he and his petanque friends usually hang out after playing. It’s as good a place as any to think of an app idea.
There are basically two ways to go about doing it as indie developers. You can try to bang out a new simple app every few weeks and flood the app store with a bunch of (mostly clone) small apps. Each is low risk and most will generate no revenue, but if one is a hit it pays for the failures. Or we could try to think of one cool idea and spend some months developing it and hope it’s a home run. We decided to try to think of a home run. If we couldn’t, then we’d just start banging out apps and see what happens.
It’s easy to have an initial idea for an app, but not so easy to think of an app that is original, doable, and could make money. We had lots of ideas, but each had a pitfall, like needing a large content partner, no way to make revenue, or just too hard to make.
Then I thought about it in a different way. Instead of trying to think of a cool app that runs on the iPhone, think of the particular capabilities of the iPhone and make an app that exploits them. So what are the capabilities of the iPhone? Text, photos, sound, video, push notification, location services. What can we do to take advantage of these features?
At this time, Ernesto was talking about Monkeyfish, an old idea he had back in the ‘90s that would “mash up” stuff from different people. I wasn’t really sure what that meant, but the idea of combining stuff from different people to make a new kind of rang with me. Also in my mind from news earlier that day was Chat Roulette, the random chat service that seems to be mostly for exhibitionist guys. I’ve never used Chat Roulette but the randomness of it intrigued me.
I was stuck on the push notification functionality of the iPhone and I jotted down a few quick notes on a piece of paper. Telephone. Push notification. Random. Time limit.
Then I asked Ernesto, “How about a game like telephone, where you record yourself saying something, then it goes to a random other person with push notification and they have to repeat it? And you can only hear it once and have only 30 seconds to repeat it. And the chain goes on until the end and you can see how the message changed.” Ernesto thought it sounded good. So we did some brainstorming.
There could be a problem with sending voice messages to random people, since you don’t have control over what they say and you can’t guarantee it won’t offend the next randomly chosen user. So the telephone game seemed questionable. But we could do something like it, where you create a topic and random people reply to the topic within a short time frame. At the end, we can censor any offensive content. This seemed more realistic and more likely to get approval from Apple. It could work for text, photos, sound and videos; it uses push notification and location services.
At the end of that beer, we had the basic idea complete. We decided to do a first version with just text and photos. What we loved about the idea is its simplicity and users can make of it what they will, like Twitter. It’s a simple, random micro-blog. The development name for the product would be Hot Potato.
Ernesto is a server-side expert, so he would focus on the back end and I’d do the app. The problem was that I didn’t know Objective C, the programming language of the iPhone. But it seemed easy enough to learn (might have been the beer thinking). The next day Ernesto lent me two iPhone programming books and I got started learning Objective C and iPhone programming.
Part 3 - App-lying MyselfDeveloping an iPhone app is both easier and harder than you think, especially if it’s your first app. Objective C is a pretty easy language to learn, but may seem odd if you already know C, C++, Java, or other languages not based on Smalltalk. And the iOS development environment, Xcode, takes some getting used to also.
WARNING: Be prepared to spend 25 hrs a day, 8 days a week on this. If you are an MFE student, then it’s a lot like that, except you need to maintain the motivation yourself, without classes, homework, tests, assignments, and deadlines.
Programming aside, developing and releasing an iPhone app is not like making a Web site. You have to get development certificates for developers, provisioning licenses for all phones being used for development, get different provisioning licenses for your testers, describe your product for the iTunes store, design the product within Apple’s interface guidelines, and so many other little things.
So next time somebody tells you “I have a great idea for an app, it’s so easy we can do it in a week,” be skeptical.
The two books I started with are Beginning iPhone 3 Development: Exploring the iPhone SDK and Sams Teach Yourself iPhone Application Development in 24 Hours. I also bought one other book later, which was very useful: The iPhone Developer's Cookbook: Building Applications with the iPhone 3.0 SDK . But the best resources are online. You can Google just about any iPhone programming question and you will find dozens of forums and blogs where other people experienced the same problems. After I got the hang of developing using the books, the Internet became the best learning tool.
Everybody learns programming in his or her own way. Some people like to read books cover to cover and understand each step of tutorials. Some people like to bang through examples waiting for something to “click.”
I strongly believe that the best way to learn is by having an app to develop. It doesn’t even have to be an original app that you want to release. You could copy an existing app. You just need to have an app in mind and work toward implementing the various functionalities it needs. The problem with just going through tutorials is that your motivation peters out. If you are actually creating something, you’ll stay interested, solving all the problems you need to solve. Programmers love having problems to solve. It’s what keeps us up until 3 a.m. without feeling tired.
This is what I had. As I went through the books, banging out tutorial apps, I always kept “Hot Potato” in mind, planning how I would code it. As I finished tutorials, I thought about how I could incorporate the new knowledge into my app, and every few tutorials I would take time out to do actual programming for my app. I really just like jumping in and playing around to learn, then reading more later to refine.
In the meantime, Ernesto was building the server application. It was only a few weeks before we had a working prototype sending messages to the server. I had even implemented the audio and video recording. But the code really sucked.
Although we had the major functionality working by mid April, the app was definitely not release ready and we had a lot of cleaning up to do. The app code was very bad and the interface was clunky. I had just been “piling code on top of code” since the beginning. I learned a lot more about good code design, so it was time to start from scratch.
I highly recommend throwing out the first bit of code written for an app and starting over, at least if you follow my method of learning (banging out code and refining it as you learn). It is a tremendous learning experience. Chances are, all the code you wrote before is garbage and you now know a lot more about good coding practices.
Regarding graphic design, it was pretty obvious that my skills were lacking. Aside from the fact that I am color blind, I only know what looks good after I see it. Good designers can envision how something should look and implement it. My “trial and error” method is just a big time waster.
Masako Masuda is an experienced graphic and user interface designer who agreed to join our company in late May. It didn’t take long before the app started looking good. Even her first day’s design put mine to shame. But she would continue to improve it and together we created a user interface flow and design that often gets the first compliments.
At the same time, we brought on Richie Narvaez (of asininepoetry.com) for writing and editing. He would be responsible for all the text in the app, the description in the app store, the press releases, and other writing that came up. It helps to have friends with such skills. We had everything we needed, except a marketing expert.
Now we needed to name the app. Hot Potato was too generic and the URL was taken. We thought the potato metaphor was cool, so I asked Masako, who is Japanese, “What’s the Japanese word for potato?” It turns out there are a few, but the one that sounded good was “Jagaimo.” I took the “a” out to make it a short “i” sound and we named the product Jagimo. Jagimo.com was available. So now we had a name. All we had to do was finish the app.
Part 4 - Time to Submit the AppThe app submission process is notorious, but not as ridiculous as its reputation. Apple is strict about what they accept for the app store: can’t crash, must adhere to Apple’s design guides, can’t have nudity or defamatory content, can’t do something one of Apple’s apps already does, etc. But it’s not as bad as people think. There are 8-10,000 apps submitted each week (including updates) and nearly all are approved.
This being my first app, I was fairly certain that it would be rejected for some technical reason. But I worried more that it would be rejected for some conceptual reason. Specifically, we are sending user-generated content from one user to randomly chosen others. If Apple believed that a 12-year-old could be receiving inappropriate content from some other user, they might reject it. If that was the case, our whole business model is out the window. Time to find a job.
There is a lot to do to get your app ready for submission. You need to submit the description, screen shots, app icons (large and small), and enter other information like keywords, age rating, and categories. Then you need to build your application in a specific way that makes it work for distribution. The documentation on this is not easy to dig through, especially if you’re working late trying to finish by your self-imposed deadline. But once you finish, you upload your app’s binary and wait.
We waited about one week before the status of our app changed from “Waiting for Review” to “In Review.” That was pretty exciting. But it sat in that status for two more days. Then it changed to “Rejected.” Why? Because when I copy/pasted the password for the Apple reviewer to use, MS Word decided I wanted to have it capitalized. So the first letter of the password was capitalized and the reviewer could not log in. Once I sent them the proper password, the app went back to “In Review” a couple days later. This time the status changed only an hour later to “Ready for Sale.”
I was shocked. I was certain that there would be some technical problem with the app that caused it to be rejected. This was my first app after all, and it wasn’t a farting noisemaker, a flashlight, or some other totally easy app. This app had to do a lot of network communication with a server, push notifications and location services. Either this means that I’m an awesome programmer or that the review process isn’t as scary as people believe.
Here was the description of Jagimo in the app store:
Jagimo is the app store's first and only social brainstorming game. Users toss ideas. Random people catch and add to them. Together they create cool and creative mashups.
It's easy to use. The jagimo starter enters a topic, creates the first message with words or photos, and tosses it. The server sends it to randomly chosen people. Those who catch the jagimo have a limited time to respond. After a certain number of tosses, they can check out the resulting mobile mashup and comment on it.
Let the Downloading Begin! Right?
The first day after our app was approved was the biggest day for us. People started registering and tossing jagimos around. Ernesto and I were having a “business meeting” at Shade that night. Our phones kept buzzing with new jagimos as we frantically responded to each and tracked new user registrations in the database with our iPads.
But the frantic pace of new user registrations and tossing lasted exactly one day. New apps show at the top of the list in the app store when first released, because they are listed by release date. Since there are so many apps released each day, your app is pushed to page 2+ very quickly, and the new downloads slow to a trickle. Then you have to figure out a way to get people to notice your app.
This is the hard part. All the other stuff about thinking of an idea, programming, designing, and submitting to the app store is the easy part. How in the world are people supposed to see your app when there are thousands flooding the app store and review sites every day?
This brings up what I consider to be our first mistake. We were very afraid that someone would steal our idea, so we didn’t do any pre-release publicity. We thought that if someone saw the description of our app in a press release, then they could do the same idea. We were also afraid that Apple would reject the app on conceptual grounds, ending our development. So our first release was probably a month too soon. We didn’t want to work another month if Apple was going to reject the concept and we didn’t want to wait a month because we thought someone else might do the same app.
Looking back, this was not smart. First off, no one had thought of and implemented the idea for the past few years. It was unlikely someone would suddenly do it. Second, the first day in the app store is an app’s big chance to get eyeballs, so you really need to publicize it ahead of time. Then people will be waiting for it and will recognize it when it’s released. The fear about Apple rejecting it on conceptual grounds was legitimate, but since Chat Roulette is in the app store, it seems unlikely that Jagimo would be rejected.
When we released subsequent app updates with enhancements, we saw nowhere near the amount of downloads as we did on day one. Always promote your app for at least a month before you release it.
This appears to be very common for just about every app submitted to the app store. There is an initial spike of downloads from people who see it on the first day, followed by a long tail of very few daily downloads. The biggest challenge at that point is to get your app noticed. The more people that see it, the more will download it. This is harder than it sounds.
Part 5 - Marketing the App Free-styleBeing a startup company with no money for things like marketing, we needed to try every free marketing tactic we could. The Internet is full of tips on how to promote your app and there is at least one book, The Business of iPhone App Development: Making and Marketing Apps that Succeed, which provides lots of good information. We had already made the first mistake, not promoting the app before release, so it was important for us to do everything we could to make up for it.
The first thing I did was to join a lot of forums that discussed iPhone apps. I posted an introduction about Jagimo and started participating in discussions. It is important to follow the forum’s rules before posting. You don’t want to look like you only came to promote your app, or to look like spam.
Next we submitted the app for review on about 75 Web sites. Since these sites receive hundreds of review requests each day, it is not easy to get them to look at our app. But we had to do this. We also submitted a press release to many of the same sites as well as tech news sites. The press release started showing up in Google searches, but it’s unclear how many people are seeing or reading it.
I also joined Meetup groups that specialize in technology, mobile apps, iOS, and entrepreneurs. These are hit and miss. Although I’ve met great contacts in some, others are just a waste of time. One that I went to was just the organizer and me having dinner. It was like a blind date.
I visited the Baruch Small Business Development Center, where I talked with a counselor who actually gave some pretty good advice. I subsequently met with the marketing specialist there. Based on these discussions, we’ll be trying some grassroots marketing tactics and hiring an (unpaid) intern from the marketing department.
How do these free marketing methods work out? Not great, to be honest. Sure, we have seen a bigger trickle of downloads, but it’s not enough to “get over the hump.” Other app developers say that the number one thing that increased downloads was being featured by Apple in the app store. How do you get featured? Well, Apple has to like the app. There is nothing we can do to get it featured besides make a good app that Apple likes. What kind of app does Apple like? Only Apple knows.
Part 6 - ConclusionsOne might be asking, “How did the financial engineering degree help, if at all?” Well, the honest answer is that it did not help in any specific way. Jagimo does not use math or finance and has nothing to do with financial engineering. But there are some less obvious ways in which my MFE helps, even for an app developer.
First, the Baruch MFE program is very demanding. I was working full time and taking courses at night, 2-4 nights a week. So my work+school day started before 9 a.m. and finished after midnight (on good days). Weekends were dedicated to homework. These happen to be the same hours required of a small business owner, especially a startup tech company. People like to say that owning your own business must be great because you can set your own hours. To which I reply, “Yes, I can work whichever 20 hours of the day I want.”
Second, the Baruch MFE program teaches C++. Although the iPhone development language is Objective C, understanding object-oriented programming is key. Objective C is like a blend of C and Smalltalk. The Smalltalk part gives it its objects, and it is very object-oriented. The other nice thing is that you can mix C and C++ into an Objective C program and the compiler takes care of it. A lot of programmers will use C when they want to get some extra processing speed or if they only know how to do something in C.
Last, having an MFE degree from Baruch makes me confident that I can find work when I need it. At this point, it’s like an insurance policy. If my company does not succeed, I believe I can find a job at a financial institution more easily than without the degree. That’s a big help to an entrepreneur because starting a business is very stressful. And if I cannot raise or earn money from the business, I will have to find a job at some point.
What’s next for Woern? Well, we are seeking investment to take Jagimo to the next level. We need to have a major marketing push and would like to develop the Android version. So for now, development is on the back burner and the front burner has a big boiling pot of business plan. On the other front burner is marketing.
Developing an app isn’t just about having a cool idea and programming it. If you intend for it to be a source of income, you need to deal with all of the other business aspects that go with it— legal, business, project management, personnel management, marketing, etc. It is true that there are many hats to wear, and if you are the type of person who can juggle hats, you just might succeed.
About the Author
Erich Wood is president and co-founder of Woern LLC, a company he started with Ernesto Santos in order to develop an iPhone app called Jagimo. The app launched in late June of this year (free in the app store) and the company is now seeking investment. Erich (known as Woody to most) graduated from Baruch College’s Masters in Financial Engineering (MFE) program in December of 2008. Starting a mobile apps development company was not what he had in mind while earning his degree; a job at a big bank seemed more realistic. But sometimes you just have to go with the flow and answer the door when opportunity knocks.