Outsourcing Mobile App Development

Outsourcing Mobile App Development – My Learnings

Update: I wrote a new post covering all my learnings with this app. Check it out!

As I mentioned in a previous post, I’m outsourcing the app development process for Digital Detach on oDesk. I promised to share my learnings so others could learn (and not repeat the mistakes I have made). This post is a culmination of my experience over the past month or so.

P.S. – the app just launched. I’d love if you downloaded it!

I’m going to break this post up into two parts. In the first section, I’m going to discuss my personal experience outsourcing, and in the second part, I’m going to give advice for people looking to outsource development.

Why Outsource?

I should begin by explaining my thought process around outsourcing the app development. The primary reason for doing this was to focus my efforts on generating interest before the app launch (aka marketing).

Building the app is not the toughest part – the biggest struggle is getting people lined up and ready to buy it when it comes out. Many technologists focus their efforts on building, and are disappointed when there’s a mediocre launch. I don’t want that to happen.

Next, I wanted to learn more about becoming a better project manager. This is a particular weakness of mine, so what better way of learning than by jumping in and figuring things out as a I go along?

Finally, I’ve worked on building applications in the past, and I’ve learned something about myself. If I don’t financially commit to a project, I don’t typically do it.

In other words, if a project doesn’t require a modest investment of money, I run out of motivation. By paying someone else to build this, it’s forcing me to follow-though. I want to recoup my investment. I also don’t have enough money to hire someone state-side for this. I need to launch quickly, learn, and if people like it, invest more time/resources. It’s an iterative process.

The developer search begins..

Digital Detach is not a complex app. It’s very basic, with the exception of one particular function. The app needed to have the ability to prevent other apps from launching. To my knowledge, this cannot be done on iOS, but there’s a bit of a hack on Android to make this work. I researched this quite a bit before I started hunting for a developer.


I wanted someone who had experience building apps like this, so that was the most important thing I looked for. I created the app posting (it was vague), set a fixed budget of $800, and started searching..

On oDesk you can invite people to “bid” on the project, so I invited several app developers with good ratings to apply for the project. Within a few hours, I had several people inquiring more about the scope of work required.

In hindsight, I should have been more explicit about the scope of the project. I should have created a more in-depth mockup of the app; it’s possible I could have filtered out candidates who weren’t a good fit (or didn’t want to work on a project like that.)


The large majority of people who responded were eager to jump on Skype to chat more about the project. In most of the responses, they included a Skype handle. It’s a clever way of selling, as real-time communication is much better than sending messages back and forth on oDesk (it’s faster communication).

The Interview Process

I created the job posting on a Friday, and had a developer chosen by Sunday. Here’s a more thorough description of the qualities/skill-sets I looked for:

  1. Prior experience with developing “parental control” features
  2. Decent English and the ability to communicate over email/messaging
  3. Decent verbal communication
  4. Responsive
  5. Intangibles (aka someone I would want to work with for future projects)

Winning candidate responses

Below is an overview of the “triggers” that made me pick him, based on the above criteria.

1. Parental control features

This is what the candidate said in the message when initially bidding on the project:

“We are already developing for a client which is related to accountability, parental control, time bounding and many more features. The functionality you are asking for is part of our existing work so we can do it in more efficient way and more quickly.”

2. Written Communication

Yes, there were occasional spelling mistakes, but the winning candidate’s written communication was perfectly fine. Looking back, we’ve sent nearly 80 messages over oDesk during this project, and written communication was not a problem.

3. Verbal Communication

The candidate was eager to jump on Skype and chat more about the scope of the project. This gave me a strong signal that if there was ambiguity, jumping on a quick call would clear things up. I was right – there have been times when we were not on the same page, and a quick phone call resolved them.

If you’re looking to outsource, test candidates by asking them to chat over Skype. I highly recommend it.

4. Responsive

The candidate was much more responsive that others (remember, this was over the course of the weekend.) While I don’t advise working on the weekend, this candidate locked up the project before other applicants even messaged me. Over the course of this project, the candidate was very responsive, so it was good to see my hunch pay off.

5. Intangibles

It’s important to work with competent people, but it’s also important to work with people that have some sense of a moral compass. The candidate disclosed that he was working on a similar app for another client, but refused to disclose specifics (he had signed an NDA). While I would have loved to see the other app, I was more impressed that he cared more about doing the right thing, than trying to win another project.

Part #2: If you’re looking to outsource your next project

If you’re looking to outsource your next project, I have a few suggestions:

Understand the tradeoffs

Many people outsource app development to save money. This is fine, yet its important to realize that there’s tradeoffs involved. If you want an app that’s perfect, hire a local shop, and spend 10x. Like every decision in life, each decision has pros and cons. It’s your job to recognize that.

A technical understanding is very helpful

Over the course of the project, there were several times that I would reference the Android developer api, find the name of a specific modal I wanted implemented, and communicate that to the developer. This saves time for both parties. While I don’t think this is a requirement, it definitely makes life a little easier.

Fixed Bid vs. Hourly?

The Digital Detach project was a fixed bid.

I’m not sure the best process here. I think there’s value in negotiating on a fixed project, but the spec needs to be very comprehensive. If you keep adding features and requests, it may frustrate your developer.


I didn’t have anyone sign an NDA. While this might be useful in certain situations, I didn’t think it provided value in this project. Plus, not signing an NDA gives the developer an opportunity to showcase the work that he’s completed.

Agency vs. Independent Contractor?

On oDesk, you have the option to select between an independent contractor, or a agency (aka development shop.) I used an agency, and I had no trouble.

  1. Having a project manager to interface between the client and developers is beneficial (in the US as well as outsourced dev shops)
  2. Specialization is key – a great developer many not have the greatest verbal/written communication.

I’m not sure what the best process is here – I believe this should be evaluated on a case-by-case basis.

Be very detailed in your spec

I still need to improve on this, but it’s extremely important to be detailed. If you hire a developer, and give him/her a vague outline of what you want to implement, the entire project is going to be a nightmare…and guess what? It’s your fault. This applies for all projects, not only outsourced ones.

I communicated primarily over oDesk messages, but if I were to do another project, I would setup a Trello board and develop a lightweight “ticketing” process.

Do you have recommendations on good mobile app developers?

Talk to Suresh.

Developers are not designers

A common tactic when outsourcing is that these people try to convince you that they can do everything in-house. While that might be true, it doesn’t mean they specialize in it.

I ended up designing the app myself. Yes, it’s not very pretty, but it looks better than most outsourced projects I’ve seen. Here’s my point – specialization is critical. If you want a decent Android app, don’t hire a PHP developer. Find someone who has experience in the area you need.

Not feeling comfortable? Start with a small project

Many of you are familiar with the notion of a trial period when working at a startup. In short, it’s an opportunity to get to know more about the candidate and how they work, before making a long term commitment. If you’re on the verge of hiring someone, and don’t feel comfortable, perhaps a smaller project would be a better starting point?

Your goal is to de-risk the process as much as possible. That doesn’t mean there is no risk though :)


The price can be negotiated. Don’t take advantage of the other party, as this will yield to hard feelings and sub-par work (the last thing you want to happen). That also doesn’t mean you need to accept the first offer on the table. Find middle ground that works for both parties. I negotiated and saved a moderate amount of money.

Establish check-ins

I highly recommend establishing regular check-ins to make sure the project is on track. The worst thing you can do is assume that a project is going to be done on time.

Would I outsource app development again?

To be honest, it all depends on the app. I don’t suggest outsourcing an app with tons of complexity. I’d prefer to have something like that close to home. If you’re building a proof of concept to validate an idea, outsourcing seems like a great option. It all depends on your project.

Biggest takeaway

If I could boil my learnings down to a simple statement, it’s that you should treat outsourced projects the same way you might treat an internal project. You should be diligent about documentation, and be explicit with your spec. Don’t be lazy, it will bite you.

I learned quite a bit over the past month. It was a very eye opening experience, and I’m glad I had the chance to do this. Now hopefully I break even on my investment.

Related Posts
iOS Acquisition
iOS Acquisition: The Black Hole
Marketing an App from Scratch
Marketing an App from Scratch: Building Pre-Launch Interest
Lessons Learned Marketing an App (or all the ways I screwed up)
I’m building and marketing an app from scratch (and sharing everything I learn)

Leave Your Comment

Your Comment*

Your Name*
Your Webpage