Jul 26, 2011

Seven Steps To Crowdsourcing Your iPhone App

Several posts ago I talked about using offshore development resources to build an entire product. Recently, a good friend and entrepreneur contacted me about doing something narrower: using a service like Odesk to get an iPhone application developed to go with his company’s existing web site.

He asked me to guide him through the process. I thought that would be useful to others, so I’m summarizing the guidelines here.

1. Draft a brief post to be used on Odesk, RentACoder, or elsewhere. This is not a project description or a product specification, but rather a specification or mini RFP for the developer you want. For example:

This project is to develop an iPhone application to accompany our existing web site. When applying, please describe the following:

a. Your experience with iPhone application development (number of years, examples of apps developed).
b. A description of your team (are you an independent developer, small team, or large company).
c. Your availability and work schedule (when can you start, what hours do you work).
d. An explanation of how you test your code.
e. A list of project management tools with which you have experience.

2. Evaluate the responses for completeness. In looking at responses, you are as interested in the completeness of a response as you are in the text itself. These are simple questions but a developer who does not respond to these basic questions is likely going to lack similar attention to detail in working on your project.

3. Draft a very simple specification for your application. This is not the complete application as you want to ship it in V1. Rather, think of it as an internal V1. Something that will show you what the developer is capable of, what they are like to work with, their code quality, and responsiveness, but will also provide you with an app you can try out internally.

The specification should be complete with screen mockups or detailed wireframes, and a description of all functional actions and user interactions in the application.

Many people start out by spec’ing out the complete V1 application they have in mind – this is a great starting point. But slim that down to the bare minimum – say, login and upload files, or login and view something, for your internal V1. Obviously, drafting the specification should be done before or in parallel with the developer recruitment process.

4. Select developers. In theory, it would be nice to conduct a complete technical interview and have a developer solve a coding problem or build a sample app. In practice, the internal V1 frequently serves as the real technical interview. That’s why it’s critical that it be well contained.

I often suggest that during the development of the internal V1, companies select two developers or development teams. After working with them both for a week or two you will get a very good sense of what you like and don’t like and you’ll have a point of comparison and greater context for making decisions about future work.

There is no reason to choose low-rated developers, developers who have no work experience on Odesk, Rentacoder, etc., or huge development shops that employ hundreds of developers. It is better to wait a few more days than to rush — it will only cost you more time later. Often the best developers are those that are independent or have a small group of colleagues, a team of, say, five or six. With smaller shops, the developers are more likely to care about their individual reputations and invest more in your code and project.

Pricing varies but based on the proposals made by people who responded to your job, you’ll have a good sense for the range.

On Odesk, employers typically pay by the hour; on RentACoder, by the project. Both services support the other format, however. Another reason to start with a small “internal” V1 is that that way you won’t be out a lot of money if you don’t like what you get. Plus, you can have the same product built twice by two different development shops, pay for both, and then decide on one for the go-forward project.

5. Manage the project. Crowdsourced /offshore development requires significant project management. A hosted ticketing (bug tracking), source code repository, and wiki system that you and the developers can access is essential. For apps that require server interaction (e.g. for login, upload, download, notification, etc.), post well-documented API’s on the wiki. Make sure your developers check in code regularly (that means every day, even if the project is just getting started). Schedule regular IM meetings to discuss questions and issues.

Skype works too, of course, but I’ve gotten feedback from developers that IM is often easier since it gives non-native English speakers a chance to compose their thoughts and read what you’re saying rather than trying to listen to it. Whatever medium you use, the key is regular communication. Test builds immediately when they are available so that there is little to no feedback loop delay. Set a good example – make sure the developer is never waiting on you.

If it doesn’t seem like progress is being made, cancel the project and start over with a new developer. It’s better to cut and run early rather than keep holding out hope that things will change. They rarely do.

Tell the developer up front your expectations on coding practice: well documented code, good variable names, and well-tested applications on delivery to you.

6. TestFlight your app. TestFlight is a dream tool for testing out iPhone apps. Instead of having to email out builds and then have people on your team connect their iPhone or iPad to their computer and sync the app, the developer uploads the app to TestFlight and the app can be installed over the air. It’s easy to track versions, and when you’re testing out a new iPhone or iPad build every day or two, TestFlight is a must have.

Regarding testing, test your API before the iPhone development starts. Provide the developer with sample code if possible; it will shorten development time and avoid confusion

Perform code reviews. Even if you’re not particularly technical, if you’re familiar with code at all, you can look for things like comments and good variable names. You are looking for highly maintainable code.

7. Prepare for V1!

It’s quite likely you’ll have to switch developers at least once if not twice before finding one you want to work with long-term. Issues that arise include developers that don’t deliver what they say they will, write bad/buggy code, or don’t have sufficient time to work on your project.

Once you find a developer or group of developers you like working with, talk about the long-term project. Developers on Odesk, RentACoder and other services move from project to project, but many will want to work with you if they know you can be a long-term source of reliable and steady income.

Of course, get feedback from your internal users on what they liked and what they didn’t and factor that into the “real” V1.

Start with a mini version of your app, until you find a developer or group of developers you want to work with long-term. Frequent communication and project management tools are critical. Spec out your design completely, down to wireframes or screens and complete functionality. Of course, ask developers for their input and ideas, but don’t expect them to define the feature set or design the user interface of your application for you. Good luck – and feel free to contact me with questions!


  • Here’s a tip for the non-technical folks out there:

    For iPhone/iPad projects, Xcode will clearly show warnings for deprecated methods (methods from earlier versions of the SDK that are no longer supported). If your first builds of the app contain deprecated methods or are using outdated SDKs it generally indicates a developer that relies too heavily on copy/paste from other projects or online forums. Looking in your code for warnings like this “stringwithcontentsofURL is deprecated” is a good way for even non-technical people to get a feel for the quality of code being written.

    Copy/paste and reusing too much code from online forums can lead to a buggy product.

    Another tip is to ask the developer to spend the first couple of hours of coding on a web conference sharing their screen. Even if you have no idea what the code itself means, you’ll be able to get a feel for how talented the developer is by how easily and confidently they get up and running. Plus the bad developers will flat out refuse to do it and you’ll cut your losses before you even get started. oDesk developer screen shots are good, but video is much better.

  • Very helpful, thanks Dave! I used this for a post today for my next small small project (https://www.odesk.com/jobs/~~1b546a75e3803344).


  • While not the point of the article (useful read btw), feel the need to point out the OTA deployment you get with TestFlight isn’t a TestFlight feature; anyone can do it.

    Can’t remember why/what now, but we moved away from TF due to issues.

  • It’s quite likely you’ll have to switch developers at least once if not twice before finding one you want to work with long-term. Issues that arise include developers that don’t deliver what they say they will, write bad/buggy code, or don’t have sufficient time to work on your project.Thanks for sharing all that great information..

Leave a comment