Outsourcing App Ideas

About a year ago, I produced two mobile apps – one for the iPhone and iPod touch and another for both iPhone/iTouch and iPad. To get the apps done, I outsourced the programming work through Elance. In this article, I’ll share my approach and some advice if you’re planning a similar project. My experience is most relevant if you’re thinking of creating a mobile app, but the same general approach should work for desktop applications, web apps, or any other project where you need technical work done that is outside your skill set. Also, I’ll cover the way I managed the process on Elance, but what I learned should largely apply to running similar projects on Odesk, Guru.com, or any of the other outsourcing services out there.

You’ll see that I decided to do a lot of up front work before hiring my programmers. In my consulting work I’ve managed a lot of large technology projects, most of them involving outsourced technical work. Some of those projects went well, and some were a struggle. One of the main difference-makers was the amount and quality of planning before technical work began. In short, the more the better. So I tried to apply that insight to my own app projects to be sure I got the most out of my investment on Elance.

The Apps

I won’t spend too much time talking about the details of the apps themselves, but if you’re interested they are the ones you see advertised on my site – Quick Rhythm and Asanamix Yoga. But, I will point out a few things that had an impact on the cost and effort involved in creating them.

• Neither is a live-action game. Games, particularly ones with 3D graphics, are a lot more complex (read time-consuming and expensive) to develop.
• I created almost all the graphics and audio for the apps myself. That meant I was only hiring out the programming work – not design or creative work. I did have to hire out the music for Quick Rhythm, and did that as a separate Elance project.
• I made the apps for iOS only. Although you can reuse content across versions, the coding for Android, Blackberry, or other devices would have to be done from the ground up for each. So, adding Android would have probably doubled the cost and any additional devices would have stacked on another 100% or so.

The Approach

I used an industry standard framework for application development as the base for my planning. It breaks up the work in to phases which should mostly be carried out separately and in sequence. It’s simple, but when it is properly applied it really works. The standard sequence looks like this:

For my project, I tweaked the definitions a bit to fit my bootstrap and outsourced approach to mobile apps:

• Discover – Deciding what the apps would and would not do, and their target markets
• Design – Detailed write-up and illustration of how I wanted the apps to look and work
• Build – finding a developer and managing the programming work
• Testing – Making sure the apps work on all the devices they should support
• Publishing – Submitting the apps to the appropriate app stores

I mentioned that I’m convinced a thorough effort in the Discovery and Design phases pays off when it comes time to start writing code. Explicitly documenting and illustrating the idea provides two big benefits. First, it forces you to really think through your design and iron out the details before the programming work begins. Second, a really good design document will help your programmer know exactly what you want, so there are fewer questions and surprises along the way. That second point is particularly important when you’re outsourcing to a programmer in a faraway land who you’ll never meet face-to-face.