Friday, December 31, 2010

Building a following for the SoDunked! app

Now, we needed to get the word out and create interest so people might buy SoDunked!

The app was submitted to Apple the Friday before Thanksgiving. We had so much personal stuff going on the next two weeksfamily visiting, holidays, cookingthat I absorbed myself in tasks. It was a great distraction for me. For Lyle, it didn't work. He was extremely antsy, checking email every 1/2 hour.

To keep our momentum going while we waited and maybe keep him from checking email so often, Lyle decided it was time to start using Twitter and Facebook to build a following. Always more interested in new tools and technologies than I usually am, this was a great fit for Lyle. He dove in, starting to post that very first day of our submission. I was starting to panic about starting the publicity before we even had an app accepted, but Lyle plowed forward. It turns out it was the right thing to do. Over the next month, from the day we submitted the app on November 19 to the day the app was accepted on December 16, he built a following of thousands.

A marketing expert could frame this better, but the idea of doing this advance work is to achieve the multiplier effect: to get even a few people to try the app and then each of them will share it with a few others who then share it with a few more, until it really adds up. Using Twitter and Facebook is an obvious way to begin this process. A small percentage of any 1,000 Twitter followers might actually read the posts, some of those might have iPhones or have friends with iPhones, and some small percentage of those will try the app.

Lyle and I brainstormed for ideas to Tweet or post to Facebook. Lyle spent significant time researching advertising options and costs that could help expand the number of followers. Together we needed to decide how much money we could afford to spend on advertising given that we were now spending off-limits savings. We opted for minimal cost and Lyle carefully tracked and measured the success of each ad we did try, canceling any that weren't effective. Mostly, we just did our own "advertising" by Tweeting and following, by writing to our networks on Facebook, and by telling everyone we knew (the latter was also done to share our excitement). It is hard to overestimate the amount of time spent on this aspect of marketing. Lyle was doing this while hanging out with the kids, while cooking, while "relaxing" in front of the t.v.--really whenever he wasn't working at his day job.

Ultimately, SoDunked! was accepted and made available for sale at iTunes just under 4 weeks later on December 16. Because Lyle had the foresight to create a following before the app was released, it gave us an audience, primed with anticipation, to announce that the app was available.

This little app went to market

When you submit an app to Apple for approval, it can take a few days or a few weeks, even a few months for apps to get approved. After reading the various developer forums, we estimated that ours should take 1-3 weeks.

The submission process begins before it actually begins. You have to look for Apple’s checklist of tasks to do before submitting and also browse the just-as-helpful checklists created by experienced iPhone app developers. Among the tasks you should accomplish in advance of submission: you want to confirm—or have your developer confirm—that  your code meets “HIG” standards (HIG=Human Interface Guidelines), that you have a logo image saved at the right size for use on the iTunes store, that you have your description written (and proofread!), and that you know what category your app belongs to—lifestyle, entertainment, games, and so forth.

One item that no checklists had prepared us for was the “EULA” (End User Licensing Agreement). Once you get into the submission form, there is an option to just check a box that essentially says your EULA doesn’t violate anything in the Apple EULA. Of course, we didn’t have a EULA. This made us pause our submission process for a while to give this serious attention. The EULA is the contract that a user signs before being allowed to receive a copy of the application. You probably sign EULAs a lot when you sign up for online services or buy products at Amazon and other vendor sites. Most people don’t really read them. They are pretty routine as contracts go, but we were just checking to make sure we did everything right. We did our due diligence and were back on track later that evening. Like everything in our experience of creating an app to sell at Apple, there were more delays and pauses than we wanted there to be and we had to decide each time whether to give up or patiently overcome them. We kept choosing the latter.

Now, a word about the submission site at Apple: the developer sites we followed had implied that submission at Apple would be easy. But then again, in 2009 we had heard that developing an app would be easy. HA!

In the beginning of this project, we actually thought we—myself and Lyle—could use the Apple Software Developers Kit to write a software application ourselves. The first realization that this was not feasible came when we learned that it had to be done on a Macintosh and we only had PCs. Then I watched the “How to get started” videos, my eyes crossed, and we started calling developers. The rest of the story of how we found developers and created the app is already recorded here in the previous blog posts.

So, when we were ready to submit the app ourselves and entered the submission web site, we should have known by the confusing—one might even say “opaque”—user-interface that we would need a developer’s help to do this. Even our developers had warned us. But, we persevered for hours until we couldn’t do any more ourselves—we answered all of the questions, uploaded the image files, and filled in the needed information. Uploading the app itself seemed like something we should be able to do, but the Macintosh requirement thwarted us again. We couldn’t even download the submission tools to assess what we were capable of doing ourselves. Our developers were correct. And, our current developer, Focus, efficiently and happily did the final stage of submission for us.

I review this all to make the point that, despite the statements of experienced developers to the contrary, there is a popular notion that anyone can do this. We are enterprising and teachable but we learned quickly that having a developer was critical every step of the way. We would still spend the long hours that we heard all start-up founders spend, but it would be devoted to the many other critical pieces of the process, not to the technical side of things.

On November 19, after our developer hit the final “submit” button for us, we received an email from Apple that said “Waiting for Review.” I think we cried. Despite a few bumps in the interim, nearly 4 weeks later, on December 16, we received an email from Apple saying that our status had changed to “Ready for Sale.” I still can’t believe it.

Our little app had made it to market. Now what?

Tuesday, December 28, 2010

Let’s get this thing finished

In the summer of 2010, we hired the new development firm and dipped into savings that we were nervous to dip into. It wouldn’t double the cost, but every extra dollar over the original estimate hurts a little. It took us a month or two to get the contracts right between us and the development firm. Once the contracts were in place, we began work in earnest.

Our intention was to do this incrementally—spend a little on the first task, assess our budget when it is complete, and, if possible, move to the next task. Lyle and I decided that this time we would tag-team with this developer so that if I am busy, Lyle can send a reply to a developer’s questions and keep things moving. Also, we decided to work with the existing code in order to save money.

The new development firm—we’ll call it “The Focus People, Inc.” (“Focus” for short)—got right to work. The process went something like this:

Week 1:
Me: Please do A, B, C.
Focus: Done.

Week 2:
Me: Looks good, but can you tweak A this way?
Focus: You mean this?
Lyle: Yes.
Focus: Done.
Me: Great. Now, can we make a new image for the email?
Focus: Yes, here are the issues and some decisions for you to make.

Week 3: 
Lyle: Okay, here are our responses and decisions.
Focus: Thanks, done. Please review. 
Lyle: Looks good. Can you adjust this or that?
Focus: Yes, now have a look.
Me: Great. Now, let's tackle D, E, and F.

You get the idea. Things went smoothly. We maintained contact. They were responsive despite the fact that we knew they must be juggling other projects at the same time and even though there were times when both Lyle and I were offline for more than a few days.

As we finished each task, we re-assessed whether we should go ahead with the next item on our list. Mostly we stayed on track, but sometimes Lyle and I deviated to get something we thought would give us more bang for our buck. And, when we got to the end of our minimal list of tasks, we did do a few other things, such as the vibration when you dunk someone on the first try. But, we had to stop ourselves or we would be spending down our retirement. We agreed that this was still supposed to be a simple version. We would get it to market, get more feedback from users, and hopefully learn whether it was worth it to add the rest of the features we envisioned. From August to October, we finished version one of the app. Then we decided the bug needed attention. It had gotten worse since the new developers had begun to modify the existing code.

It took about 2 months of paperwork and planning and then a few more months of development. Lyle and I managed to stay on top of things despite a child’s tonsillectomy, a vacation punctuated by an ER visit for one of the kids, and both of our day jobs. Lyle was traveling more for work and I was juggling more at home and work. Luckily, we both had iPhones as our cell phones by now and we used them to keep connected to the developer even when we were out of state or at the hospital. This was a tough adjustment for me who likes to be disconnected from technology, but I stayed focused on the goal: get this app to market.

Finally, finally, by about the middle of November, the bug was truly fixed and we agreed it was time to see whether Apple would accept this.

We submitted the app on the Friday before Thanksgiving.

Monday, December 27, 2010

Keep going or kill the project?

Lyle and I spent the next few weeks reviewing our situation so we could make an educated decision about whether to try to finish this app. We tested the app that Johnny delivered, asked an expert to evaluate the code, and made a list of what might need to be done to make it usable as our version 1. We looked at our budget—which was still zero unless we used savings that had not been set aside for this project—and we talked at length about how much of our savings we would be willing to spend to keep going with this project. We had to consider that we might not get the money back. We also resumed the search for a developer so that we could make reasonable cost estimates.

The testing revealed a short list of things that were showstoppers for us. Primarily there was a bug. In software development, there are always bugs and, given time, developers can figure out what is causing them and fix them. Sometimes it takes a lot of time. There are some bugs you can look past and just live with but this one was  big—the app would just get stuck in between steps for no particular reason. There was no discernible pattern to when this occurred so we knew this could be a big time eater.

Our friend, Mike (the family friend who had helped us right at the beginning of our brainstorming about the app last year) gave us a frank assessment of the code (thanks, Mike!). Without getting into the techno-speak of it, there were a few things he thought might make the code hard to build upon and some things that might cause problems.

The list of what Lyle and I would want to do to turn this prototype into a "final" version 1 was short: fix the bug, add sound, add the social networking functionality. There were some things on our wishlist, but we were trying to be minimal for now so that we might be able to afford to do this.

Looking at online advertisements, Craigslist, and the many job boards for technology consultants, we eventually discovered a software development firm that could give us a cheaper rate and had demonstrated experience with the development and completion of iPhone applications. We spoke to the owner of the firm, quickly felt confident in his expertise and decided to get an estimate for what it would take him to complete our “version 1” app. We gave him a list of the tasks we thought were the minimum features and fixes we would need plus our wish list. He came back to us with a few options.

Taking all of this into account, we decided that yes, we would keep going. We were willing to use our savings to advance the quality and fun of the app and hope that Apple would accept it. 

Tuesday, December 21, 2010

Turning pictures and ideas into code

Now, we needed Johnny to stitch the idea in the wireframes together with the graphics to make the app.

In a big organization where there is an IT group and a client team—all working on this as their primary job—the process goes something like this: The developer(s) from your IT department ask a lot of questions via email or meetings until they understand what you need—both in the wireframes process and during the actual development or coding. You, the client, need to be available whenever the developer is working so that waiting for client feedback doesn’t leave the developer twiddling her thumbs at the often more than $100/hr rate. The developer shows you mockups and you give feedback. The developer revises the mockups and you give more feedback. IT develops the first “build” (build=working version of at least part of the application) and you test and QA for proper wording and user-interface (ui) issues. You might bring in users to test or give feedback on the ui. Then you probably repeat this several times. It is an iterative process. All of this back and forth is important so that the developers can get feedback before they go ahead and build your entire app based solely on your original wireframes plus whatever they imagine themselves. The process can be short or it can be long and involved. Either way, the developer really does need to stay current on your evolving ideas and input and you need to stay current on where they are in the process and what they need to keep moving things forward.

With us—two people doing this on the side of our primary jobs and our families, this back-and-forth flow never flowed. Johnny (luckily for less than $100/hr) would find time to work on the app and then email me with a question that I couldn’t make time to answer for several days. Then, when I did get back to him, he would be busy and couldn’t work on the app again for a week or two and this same pattern would repeat. Sometimes weeks turned to months. Here’s a sort of timeline of our working relationship (condensed and approximated):

Week 1:
Johnny: Can we wait a week to start, we are moving into a new house and…

Week 2:
Johnny: Here is a mockup of the photo capture screen.

Week 3:
Me: Sorry it took me all week to get back to you, but here are my comments about the photo capture.

Week 4:
Johnny: My partner is going to be away for a few weeks and I have to
take care of the kids, I’ll try to work on this at night after the kids are asleep.

Week 5:
Me: Hello? Are you there?
Johnny: Work got busy, be back to this soon. 

Week 6:
Me: We leave for a driving vacation to see family tomorrow without a
computer.
Johnny: I’ll have something for you when you get back.

Weeks 7-9:
Johnny: Let’s meet so I can show you the screen capture on my iphone. 
Me: Is Xpm good? I have to bring my 3 yr old.
Johnny: Yes, maybe, no, sorry, got busy at work.

Week 10:
Johnny: I am going to work on this non-stop this next two weeks.
Me: Great, but I will be away for a week without computer so call if you need me (but I forget to turn on my phone for most of the week).
Johnny: Oh no, my son spilled coffee on my home computer. I'll get back to this soon.

Week 11:
Johnny: Here are some more screen shots.
Me: Continue to pay for work done.

Week 12:
Johnny: Getting hung up on ball-throwing. I know a physics guy who can help.

Week 13:
Physics guy: Delivers his code.
Johnny: Home with sick kid.
Me: Home with sick kid.

You get the idea. Johnny and I both worked hard and juggled this into the mix of our lives as we could. After 3 months, we had spent about half the estimated development cost. After 6 months, we had spent all of the estimated cost—right up to the upper limit of the range—and the final draft was not yet finished. Johnny, an upstanding guy, worked for free at this point. 

Some of the animation was particularly challenging since—despite being an animation expert in other media and also having worked on a few iPhone apps—he had never animated within this environment. This was draining his time and was not only delaying the project, but was demoralizing for Johnny. I was now spending my “app” time working on a way to salvage the project. Whatever plans Lyle and I had mapped out were quickly changing due to time and financial limitations.

So, even though I had questions and corrections and changes and comments, we just didn’t get to most of them. In the end, Johnny delivered a version 1 app that was, essentially, what we had discussed. But, there was no music, no sound, no Facebook or Twitter linkage and it was pretty clunky and a little buggy.

Version 1 came one full year after my first meeting with Johnny. That was about ten months more development time than we had anticipated (our original estimate was for 1 month and I had secretly bet on 2-3 months). Lyle and I quickly began planning for a way to turn the “version 1” app from a prototype into something that was more than a prototype, but not yet our “dream” version.

At our last meeting, Johnny said he wouldn’t be offended if we found someone else to develop the app and he even seemed relieved when I told him that we might.

Now, Lyle and I had something that wasn’t a functional app that we could submit, we had spent our development budget, and we had to decide whether we should, in fact, hire a new developer. We never had any luck before with finding other developers so why would we now? And, how much more were we willing to spend to advance the quality and fun of the app versus how little could we get away with adding before we just submit it to find out if Apple will even accept it?

We had to decide whether it was time to keep going or kill the project.

Saturday, December 18, 2010

The work begins, Part 2 – "Graphics needed"

Now, we needed to create the images for each screen. Correction: we needed to find someone to create the images for each screen. And it needed to be someone who could do animation.

I can draw and I can figure out a lot of things, but I had my doubts that I could figure this out—what software to get, how to use it, which file formats, how to do the animations—in a reasonable amount of time. Luckily, Johnny knew someone who charged a very reasonable rate. He didn’t live in the area, so we communicated entirely through IM and email. When he—let’s call him Sully—sent us initial samples of what he could do for us, we liked them so much we immediately said “yes, let’s do that!”

An aside on selecting graphics and styles:
It can be intimidating to make a final decision about an image that will affect the look of your product for a long time. For some of us, it keeps us up at night debating over the choices and then wondering whether we made the right choice. This is when you have to review your goals to assess how critical a particular image needs to be and give yourself a time limit. Get a friend to help you. Find something that you do like on someone else’s web site or somewhere so you have a baseline in your mind. I bet there are some good books and blogs on this subject, but Lyle and I never did find the time to look for them. We tapped a few good friends and used their reactions to help us decide.

It also can be hard to tell someone “I don’t like that” or “can you make this darker and move this over to the left?” You have to summon your inner “bossy-ness” and say what you think. Designers expect this. They expect to make some changes to the things they submit for your approval. Ask for what you want.

Now back to the story:
With Johnny, I created a list of the images—based on the wireframes—that we would need to make the "version 1" screens and, bit by bit, I sent this list to Sully. Within a week, sometimes within a day, Sully would send us his interpretations. He sent them as “png” files.

This was pretty straightforward. We went back and forth a few times to adjust the colors, change the type of balls used, add a basket for the balls, etc. Each time, Sully sent the images to me to review and, once I approved something, I sent it to Johnny. Sometimes, the developer works directly with the designer and acts as liaison between the client and designer. We found that making me the liaison worked better for us. 

At the beginning we just needed a few images. There was a static image of the tank and background with the balls and target. There was a person on the dunking seat. Sully also designed "buttons" and a menu and the logo. Later, when we were a little further along into the coding and saw how the action should work, Lyle and I went back to Sully for a second round of images for the animation of the person falling and the ball hitting the target. Sully delivered on time and billed exactly what he said he would. It was affordable and the work was good.

Now that we had the images, it was time to focus on the code behind them.

Thursday, December 16, 2010

Breaking News

Our app was accepted at Apple today and is now available on iTunes!
http://itunes.apple.com/app/sodunked/id406270928?mt=8

The blog will continue (the story is only just beginning).

Check back here soon for the next post.

And, don't forget that you can click the "Follow" button at the top right to become an official "Journey to an App" fan.

Tuesday, December 14, 2010

The work begins, Part 1 – “Building the skeleton”

In May of 2009, about a month after we first met Johnny, we began the real work of making the app.

It began with me needing to tell Johnny—in more detail—what we wanted so he could turn the idea in our heads into an iPhone application. To do this, Johnny asked me to create “wireframes.” Wireframes are just what they sound like: a skeleton of the idea sketched out in frames that represent each step or screen. Often, in the world of web or software development, you hire a design firm to listen to you talk about your idea and they produce the wireframes for your technology staff to use as a skeleton or even a prototype. If you find yourself needing to create wireframes, you may in fact want to hire someone to help, but you can do it yourself. You just need to convey the steps and ideas in a logical, visual way so that someone else can understand better what you have inside your head. You can use any program that can make a flowchart or you can write it on sheets of paper with a pen.

I took the written description that I had sent to our family friend, Mike, several months earlier and put that into outline form in a word processing program to help me see the sequence of steps. After a little editing, I tried to imagine the steps as the sequence of screens you would see in the application and I wrote each of these out in a “frame” using a basic paint program such as you can find on any computer. I did this mostly with just words and arrows like a flow chart, but I did draw some pictures, too. It has changed a bit but here are a few thumbnails of the original wireframes to give you an idea of what they can look like.

Frame 1

Frame 4

Frame 7

Frame 9


Johnny looked these over and asked me questions about anything that didn’t seem clear to him, such as “where in this sequence do you want the user to click to take a picture” or “what if in screen 3, someone makes C happen instead of just A or B?” We spent some time emailing back and forth about the steps and I made updates until we agreed it made sense.

From this process, we determined that the “version 1” of our app—the prototype—would be just a few screens. There would be a screen where you could take a photo from your camera or saved images and a screen where the head would appear on a generic body sitting over a tank (with a generic background and some balls in the foreground to throw at the target). Then, after the player throws the balls and hits the target to get the person in, there would be one more screen with a menu to let you go again or send the final image as an email to someone or possibly post to Facebook or Twitter. Essentially, this was 3 screens. How complicated could this be? The schedule was for this to take 1 month. I secretly bet on 2-3 months.

Sunday, December 12, 2010

Looking for a developer

We had been looking for developers since day one, but with the change of focus from “the whole shabang” to “simply a prototype” or version 1, our efforts intensified. We wanted to know soon whether this would be a viable project and, if not, move on to something else (or at least resume normal lives—you wouldn’t believe how much time it takes corresponding, reading, calculating, and chasing leads and resources for this app).

For this “version 1” app, we envisioned spending a couple thousand dollars for development in a 2-4 week time-frame. We knew the dollar amount was low for development. It was what we thought we could afford. I even considered figuring out how to do it myself, but gave that up very quickly after the introduction to the “how-to” video made my eyes cross. Our interest in an additional source of income was driving us to take a risk and make this app happen, but our fear of eroding the savings we both had spent years creating kept us feeling risk-averse. I imagine this is the conundrum that many potential entrepreneurs feel and, for many, stops them in their tracks. We may yet stop in our tracks, but we wanted to go a little further to see if we could make it work. So we picked a number we were mostly comfortable with, closed our eyes (maybe left one eye open), and stepped forward. It’s just a prototype, right? We were determined to get at least that accomplished.

Several people suggested we talk to local schools and maybe a student would want to develop our app as a project. This seemed like a great idea, but the reality wasn’t practical for us. We were concerned that our project would need to be modified to suit the scope and time-frame of the school, that the quality of the product could be “hit or miss” and that, once the official project was over, there was little to no follow-up available to fix bugs or add features. Also, I once had worked with a talented student on a very small technology project and, despite his good intentions, other school work and social life often took precedence over my deadlines so my “very small” project dragged on for over a year. And, in this case, the person had not yet developed organizational or communication skills as far as maintaining notes from our conversations or sending an invoice when he needed to be paid. This made for a messy and difficult process. I had not found this student through a local university so he was not doing this as an official school project with a supervisor. This meant I had no one to go to when I had a problem with him. If you find yourself considering a student to do some software development for you, I highly recommend talking to an academic department to find someone who has a supervisor or a mentor so that the student has someone to guide him or her through difficult tasks and act as an intermediary if you—or the student—have problems in your relationship.

With the student idea crossed off of our list, my husband and I continued our search for experienced developers that might charge less than $100 per hour. We didn’t have much luck finding people at lower rates who knew how to develop for the iPhone and most that we did find were not local—we got nervous about working with (and paying) strangers. That said, I was feeling so desperate to find someone that I once gave my phone number to two guys at the airport who were reading a book about developing for the iPhone (never heard from them).

Our big break came when a trusted colleague from work knew someone who had been developing iPhone applications as part of his job within a university and this guy was looking for side work to help support his family. I spoke to him by phone—he sounded excited and had ideas for how to use existing game engines and ways to simplify my idea for a “prototype”—and he charged under $100 per hour.

We met in person for about an hour and the developer guy—let’s call him Johnny—estimated that he could do a simplified “version 1” of our app in 40-50 hours, including the artwork, animation, and some physics. Woo hoo! He gave us a time and dollar amount range within which he could complete the project and felt confident he could do it at the lower end of the range. This was all so reasonable and easy! It was a *little* more than we had hoped to spend, so my husband—I think I ought to give him a name here too…how about “Lyle”—and I crunched the numbers, scrunched up our faces, and took a leap.

Thursday, December 9, 2010

Let’s get some money!

Along with the more concrete estimates for the cost of development, we were thinking about basic legal work we might need, the state fees for creating a company and incorporating to protect ourselves, as well as the cost of marketing—which many experts claim is the missing piece of the iPhone app dream. At this early stage, we thought “Investors. That’s it, right?”

We spoke to people in our networks and studied print and web sources for standard valuations for products or companies like we imagined ours would be. We looked for information on what investors want and what makes investors want to invest. People told us that to arrive at a valuation, you should consider your assets, how much the idea is worth, and how much money you would be willing to give it up for. At the moment, our only asset was our idea and our sweat equity spent thus far on the research and planning. We had no idea what that was worth to us—$5,000…$100, 000…more? People also told us to think about how much of our company would we be willing to “give away” or “share” with other people—10%, 25%, 49%...more? Around that time, a new t.v. show began about entrepreneurs making pitches for money to a bunch of successful businesspeople. We watched it a few times and each time took away the impression that when the investors were interested in something, they always wanted to have a controlling interest to insure they would make their money back and more. The entrepreneurs would ask for huge amounts of money (give me 1 million dollars, please) and offer a 10% stake in the company at which the investors usually laughed. Our print and web research was leading us to the same conclusions—to get a lot, you have to give a lot. That is just how it works.

Also at this time, a few other factors surfaced.

My youngest brother, an MBA student at the time, said that “showing an investor that a consumer actually wants to buy your idea is key.” He suggested that if we could collect data saying that people would buy our app, we would have a case for investing in our idea. With his help, we developed a market research survey for existing iPhone users that included such specific questions as “Would you pay for this app?”

Once we had our survey ready, we wondered whether both the potential investors and the survey-takers would respond better if they could see screenshots or a prototype of the app. Then we wondered “what if maybe we just use our own savings to fund a prototype and maybe, if we want, we will submit that prototype to the app store and make enough money from that to fund the rest of the development?”

On the developer discussion boards/forums, there was a lot of talk at this time about apps that were rejected for odd reasons and frustration that there were no clear rules for why Apple accepts or rejects apps. Developers were feeling like creating a substantial app was a big risk for an individual or a small company to take. We took this under consideration and it reinforced our plan of the moment—that we should submit a prototype just to make sure it will be accepted before we spend $50,000 of anyone’s money.

So, now we were doing exactly what we had anticipated—“a little of all 3”—maybe seeking investors, maybe spending our savings, and maybe reducing the scope of the app. It was getting to be time to find a developer who could help us get a basic application developed within our budget.

Wednesday, December 8, 2010

Research, Part 2 – “Is this app idea technologically viable? We need an expert’s input.”

During the app-immersion phase, I did manage to keep focused on whether my particular idea had been done already and whether the idea seemed viable given the kinds of things people were already doing with apps. In addition to searching the app store for hours every day, I combed app review sites, read lots of technology blogs, and searched major media for clues. My husband and I also talked to friends and family about their iPhone experiences. To my surprise, there wasn’t anyone else doing what we wanted to do.

An aside:
I really was surprised that no one was doing what we wanted to do. Generally, I come up with an idea and by the time I start to be serious about it, someone else has already produced and sold it and done it well. For anyone who has an idea and the dream of doing something about, I strongly encourage you to at least do the research and talk to people. You never know, your idea might just be the next big thing. Best of all, you can say you tried it. That may be my new life motto: “At least I tried it.”

Now back to the story:
Most importantly, the research revealed that our app idea was viable. There were some apps doing some of what we wanted to do—utilizing the camera, linking to social media sites, and using the touch screen or the accelerometer to throw. Based on this, we were ready to assess the real technical and cost feasibility.

Luckily, when he gave me the phone, Dad also gave me the email address of a software developer and he now said “talk to him, maybe you guys could make it work together.” This person was a very old family friend, but not someone I really know. However, the guy is trustworthy and knows a lot about application development and something about Apple, so I contacted him to see if he was interested in working on this or advising us. I cannot say enough about what a fine person and talented developer he is. We lucked out.

This person—let’s call him “Mike"—asked me to write a brief description of the app idea. I spent some time crafting a proper description in narrative form which proved very useful throughout this process. I went back to this description again and again to check my original ideas and find wording to re-use in other correspondence about the project.

In the end, Mike couldn’t take on the project, but was extremely helpful. First of all, he told us the app sounded technologically viable. Based on my description and the hourly rate of an experienced software developer, he estimated it would cost at least a few tens of thousands of dollars to create the app the way I had imagined. Oyoyoy. He cautioned that these kinds of estimates *could* double once the process begins. I knew this to be true from my professional work—that when the IT department develops and enhances applications for my team to use—the estimates are only estimates. In those situations, when the application is partially built and needs more time than expected, either the scope of the project is cut drastically or the budget is increased at the expense of something else.

Well, you can imagine that we took a little time to think on this new information. We figured we ought to take his estimate and double it and that number was pretty big.

So, we did some additional research specifically about cost. We read blogs, articles, developer forums, whatever we could find. The basic development cost estimate my husband and I compiled from all of this was that an app with graphics and animation that has all of the features we want would take 100-200 hours, typically at $150 per hour, for an experienced developer. I found a few people online saying that an app like ours might cost even more—“at least $50,000” to “do it right.” Well, this was beyond anything we could afford, especially not knowing whether we would ever get it back. Apple shares the profits, but there have to BE profits and a LOT to make it work for such a high price tag. Now we needed to consider 1) whether to seek investors, 2) whether to spend our savings, 3) whether to reduce the scope of the app, or 4) possibly a little of all 3.

Monday, December 6, 2010

Research, Part 1 – “Let’s get some apps!”

My idea was to have a virtual dunking booth where you could put someone you know—or maybe someone you are glad not to know—in the booth and dunk them. Wouldn’t you feel better if you could dunk someone who is really driving you crazy? Of course, a real dunking booth would be best, but wouldn’t it make you feel pretty good to dunk the person over and over while sitting right in your own home or desk or café (or while looking at them and they don’t why you are laughing maniacally)?

I tapped my family to brainstorm about how this could work as an iPhone app. We decided the first thing to do was to take Dad’s old iPhone and try lots of apps.

Because it was an ‘old’ phone, I was able to set up an iTunes account without signing up for phone service (phew). We scanned the app store via the various “top” lists and “favorites” lists. We did searches on many different terms to see what was there that might be like what we wanted to do—or might just be interesting to each of us. Initially, we focused our search on the “entertainment” category where we assumed our app belonged. We quickly expanded our search to look at games and other categories for research and for fun. I am sure we barely scratched the surface despite having read through several 100s of descriptions and downloading many of those. From this effort we found a lot of junk, but there were also some great apps. The things we all discovered through this research, even when an app didn’t directly relate to our own app idea, taught us how to use the phone and how other people had imagined ways to use it. This was invaluable.

In case it is of interest, here are some of our favorites from that early research: We all liked iChalky. I enjoyed Peggle and Bookworm (hours of sleep lost…) as well as Fluid and Spawn. The kids (ages 3-10 at the time) loved Jellycar and Trace and Toobz. My husband gravitated to Scrabble and some news apps. Suddenly, everyone was saying “where is MY iPhone?” We got a little distracted by the fun of it all.

It WAS fun, even for me. I am not much of a technophile, so it was enlightening to learn first-hand what everybody was so excited about and to feel it myself. The interface was so different than anything I knew about. When I began, the concept of playing games on a device or reading or making art on it was absolutely alien to me. I was thinking to myself “how can I effectively develop an app for a platform and an audience that I know nothing about and for which I have no burning yen?” As we worked our way across the sea of apps, this changed, significantly—necessarily.

Sunday, December 5, 2010

It all began when...


In winter 2009, while brainstorming for ways to earn extra money on top of my day job, I had an idea that seemed like it might lead to something. I thought of a sort of game that could help you let off steam when you are annoyed at someone without driving them crazy or hurting the relationshipsomeone like your boss or your spouse or even the dog next door who barked all night long. I imagined it as a Wii game, but after a little research I decided that was too difficult and costly to pull off. Then, I thought, “maybe I could create a web site around it and find a way to make money from that. I know how to make web sites and I could get help.”

I mentioned this idea to my dad, a seasoned businessman. As I described a rich interactive web experience, he interrupted with “how are you going to monetize this?” “Hmm,” I said aloud and rambled on about generating hits to attract advertisers or maybe setting up a paid members-only space. My dad interrupted again to say, “I think it should be an app for the iPhone.”

Apple had just opened the “app store” about 6 months before. The typical price for a paid app was 99 cents and the developer could keep 70% of the revenue generated (pre-tax). We knew some people with iPhones and they were buying all kinds of apps, even silly ones. This would definitely be more of a silly app than a business app. (Silly app or no, I imagined that it could help people vent off steam instead of directing it at their loved ones.) Then, Dad interrupted—againand said, “I got a new iPhone last week. You can have this ‘old’ one [hands me phone] and just see what happens.” So, in spring of 2009, armed with an idea and an ‘old’ iPhone, my husband and I began our journey toward creating an iPhone app.