F|R Crib Sheet: How to Source Good Offshore Developers

Matt Rogers on June 14, 2008

If you’re bootstrapping your startup, offshoring your web development is a great way to save money. But it’s also fraught with risk. Working with remote contractors makes it far harder to manage project development and communicate ideas. Taking proper steps to protect yourself is crucial.

I’ve been bootstrapping my e-commerce startup, Aroxo, for the last year and blogging about it for Found|READ and on my own site. My previous post explained how to use your network to build a quality list of prospects. Today I’ll tell you how to vet the list to select the right offshore developer.

Step 1: Send a “Request for Information” to Prospective Vendors:

The RFI is a questionnaire you will draft to help you determine which developer can deliver your project within your price range (here’s a sample). Your RFI should produce the following data:

  • Vendor’s vital statistics: years in business, number of employees, rates for all billable staff.
  • Currency the developer will use to invoice.
  • Confirmation or denial of a fixed cost for your project (which you want)
  • Description of the vendor’s typical projects (How big are they? How long do they last?)
  • Vendor’s technology certifications and other technologies they can support.
  • Source of the vendor’s development design (in-house or sub-contracted?)
  • 3-5 customer references.

    • Additional RFI Tips:

    Include a hypothetical “technical problem” relevant to your project and ask the developer to show how they would solve it. For customer references, ask for projects similar to yours that were completed for clients physically near to you so you can arrange to meet them in person.

    Worried about your IP? Don’t discuss the specifics of your business in the RFI. Describe the type of business that you’re launching in general terms (e.g. e-commerce), or refer to similar companies by way of description.

    Give the vendors two weeks to respond, and an opportunity to ask you questions. Include your deadline(s) so the developers have a timeline. Not every vendor will respond to your RFI. Some will, but won’t answer all your questions. Others will will send you “documentation packs” that contain all the answers, but not in the format you requested. All of these companies should be dropped from your list.

    Step 2: Vetting Your Vendor Prospects

    Two weeks after you’ve issued your RFI, you will have all the responses you’re going to get. (Don’t bother chasing companies that don’t reply.) Now you must work through the list until you have at least four — but no more than seven — prospective developers. This is an important yet difficult step. First, think about who your ideal vendor is. Identify the criteria by asking the following questions:

  • Do you want to work with a small company, or do are you looking for a larger company with ISO or CMM certification?
  • Do you have a particular development methodology in mind?
  • Do you want your system built with a particular technology?

    • Now you’re ready to start “the sift.” First, remove any companies that don’t fit the criteria established above. When I read through my RFI responses I arrange them into three piles: Yes, No, and Questions. I then put my additional questions to the vendor again, and update. I continue this until I have complete Yes and No piles.

    When in doubt, go to their references. Don’t just ask if the developer delivered on time and to budget. Also ask: Have they given the vendor any new work? Will they in the future?

    The reason I recommend getting to preferably four and no more than seven potential vendors is that you don’t want to take too many through your bidding process because you don’t want any more of them than necessary to know what you’ll be building.

    If you don’t end up with four candidates, don’t go back through your pile. Approach new developers until you do.

    Matt Rogers is co-founder of Aroxo.