Practical tips for outsourcing your web app

If you are developing a web application, do you build it in-house or outsource to a specialist firm? I’ve experienced both alternatives so far – RedBubble built their application in-house, and my new venture SoftwareShortlist has outsourced to an overseas developer. Each path has its own advantages and challenges, so which is right for you will depend on your capabilities, resources, and preferences.

If you are considering outsourcing your project, here are some tips and advice from our recent experience (which I should say has been very positive overall):

  • Be clear on what you want at a strategic level. This includes knowing what you are not going to do, which helps avoid scope creep, and most importantly, stops your project looking and working like every other one out there. We found it useful to do a few iterations refining the business concept before getting the developers to start building it, and to have a reference set of peers/competitors/analogies so we could explain our similarities and differences accordingly. 
  • Check the developer’s portfolio and references. Define what skills and experience will be important on your project, and rate candidates against this. Ask their clients what they could have done better, and where their limitations are. Check whether they have been used for subsequent work (or if this is intended), and whether they are currently working for them. Trust your gut, and listen to what is not said as much as what is said. And don’t go for the cheapest – pay a bit more to get the right firm.
  • Apply a true “partnership” mentality. Don’t try to maximise what you get out of the project, but instead make sure the deal works for both parties. Chances are you’d appreciate their willing cooperation down the track when you need support or further enhancements done. A good way to build trust is to recognise when your decisions create extra work for them and be open to alternatives that deliver similar outcomes more easily.
  • Build a prototype. Even if it is just on paper, the process of going through the detail of how things will work really clarifies things… and saves big problems later. We found an excel mockup with macros handy for our prototype, and this put us in a good position to explain our algorithm to the developers. 
  • Be explicit about your assumptions. We found that most misunderstandings come down to the “blind spots”, not the known biases or quirks of each party. Ask questions to explore the assumptions that the developer is making. Work through specific examples and user cases to flush out everyone’s assumptions. And the earlier, the better.
  • Determine who is leading the actual work. Make sure you build a good relationship with this person! It is common to have the sales guys or directors sell the project, and then a separate lead programmer who manages it day-to-day. It’s the lead programmer who will make or break your project.
  • Take the customer’s perspective.  It’s your job to be the voice of the customer. Step back and try to view the user experience objectively. Or better yet, arrange to get real customers to test it out. Don’t be afraid to rock the boat or make significant changes to act on this feedback.

Let me know what your experience has been. Do you have other tips to add to these? Or a different perspective to offer?