We wanted to build Trusty’s off-shore, we knew that from the start. The main reason was cost, of course — with extremely limited funds, we needed to take advantage of developing-world pay rates. Building and launching successful Internet products requires tremendous work, coordination, and luck, even under the best of circumstances. Doing so in coordination with a team on the opposite side of the planet (with the time differences, language barriers, and cultural hurdles) seemed just short of impossible. It was daunting and risky, but when you’ve got nothing, the saying goes, you’ve got nothing to lose.
And once you accept the risk, there’s a powerful attraction: the chance to collaborate in the global economy. I’ve read The World is Flat, and followed the capitalist exploits of Shanghai, Bangalore, and Hanoi enough to know that I wanted a piece of the action. We needed a prototype — a basic web application which we could take to market. We wanted it fast, and we wanted to eventually extend it — to scale without having to toss out the source code. But most of all, we wanted it cheap.
This was all back in February of 2008, when our business was still on the back of an envelope. But having found an development partner, and experienced first-hand the challenges and rewards of low-budget off-shore collaboration, I wanted to share some of the lessons learned. I’ll start with some thoughts for selecting a partner, and follow up with a post on managing the development.
We were committed to developing Trusty’s using Ruby on Rails, but these points could apply to selecting any off-shore partner:
1. Define your Product. Before you reach out to potential partners, it’s important that you have a clear idea what you want to build. Agile development and the requisite lack of documentation is all the rage, and there is much to be said for evolving products to suit real users, but doing so with an offshore partner (at least for an alpha, or proof of concept) is recipe for disaster.
If you’re bootstrapping your business, you need to know exactly what you’re buying, and how much it will cost. In the language of contracts, that means a detailed scope of work (SOW), and a fixed price budget. Don’t leave home without them.
For the purposes of comparing potential partners, and getting similar proposals (and quotes), the traditional means is with a request for proposal (RFP). I wrote one for trustys.com, but the truth is that any detailed requirements document could serve this purpose (and be repurposed as the SOW). The RFP merely supports the product requirements with additional expectations (coding standards, timelines, team roles) that are worth capturing. (Here’s the RFP we submitted for Trusty’s: http://tinyurl.com/6ujj24)
Not that every last detail of your product needs to be nailed down before you engage, just high-level requirements. Our talented designer, Jane Mount, worked on much of the site architecture in parallel with development, and provided direction (wireframes and design comps) on an as-needed basis, but we were always one step ahead of the development team. Lack of product definition leads to ambiguity, and ambiguity has been the downfall of many well-intentioned off-shore projects.
2. Narrow the Field. When we decided to build trustys.com with Ruby on Rails (RoR), I assumed we would have relatively few off-shore partners to choose from. RoR is a new framework, primarily adopted by Web start-ups, and I wrongly assumed it was incompatible with the enterprise clientele of international development shops. It turns out that googling ‘ruby on rails offshore’ returns more than a few matches, hundreds more, and determining which of the contenders from around the world have the chops to deliver a scalable web application is a time consuming process.
Unfortunately, there’s no easy way to narrow the field to the half-dozen or so companies with whom you’ll want to share your RFP. It’s a matter of reviewing their web sites (and blogs), contacting them for additional details, and then making a gut decision about which ones seem legit.
One helpful resource was www.workingwithrails.com, an RoR community with an extensive international footprint. There isn’t much detail on the hundreds of companies indexed on the site, but there’s good insight into the ‘authority’ and ‘popularity’ of principals behind them, and their involvement within the Ruby community.
Ultimately, we sent the RFP to six companies:
- • Railsware – Kiev, Ukraine (Yaroslav Lazor: yaroslav.lazor@railsware.com)
- • Confiz – Lahore, Pakistan (Muhammad Raza Saeed: raza.saeed@confiz.com)
- • Railsfactory – Chennai, India (Dinesh Kumar: dinesh@railsfactory.org)
- • Vinsol – New Delhi, India (Manik Juneja: manik@vinsol.com)
- • RoRCraft – Sydney, Australia (Rex Chung: rex@rorcraft.com)
- • JoshSoftware – Maharastra, India (Gautam Rege: gautam@joshsoftware.com)
3. Do the Diligence. The responses from companies varied widely in terms of detail, quotes ($7,360 - $45,000), and timeline (7 - 11 weeks). Further narrowing the field to three finalists was straightforward: Vinsol pulled out (too busy), and the two highest bids had the least impressive proposals.
In the end, we set up skype conferences with Confiz, Railsfactory, and JoshSoftware. I was accompanied on my end by Mohammad Abed, a talented software architect and ruby advocate, and our discussions were primarily with a CEO/CTO duo (though they often introduced proposed team members). The narrative of these discussions followed the proposals – their approach, the team, previous experience, and timelines, but there were a number of questions we posed to all three:
- 1. What do you think of our business, and what do you see as the value proposition?
- 2. What projects have you completed that required similar features and functionality?
- 3. Describe your development process, from soup to nuts, for a typical project.
- 4. How do you handle: project planning, team communication, quality assurance, and change requests?
- 5. What tools do you use for project management, version control, and bug tracking?
- 6. Describe your coding standards for Ruby on Rails and CSS/XHTML.
- 7. Can we review the source code for applications you have completed?
- 8. What RoR libraries or plug-ins would you consider for search and geo-locating?
After the meetings, I followed up with the references they provided, as well as (when possible) former clients they didn’t cite as references.
In the end, it was a toss-up between Confiz and Railsfactory. We liked the principals at both companies, they had comparable experience, and both seemed capable of delivering a working prototype of the Trusty’s product in a matter of months. Ultimately, the decision came back to cost – one bid was significantly lower than the other.
Stay tuned for our next post, when I’ll share who we selected, and our experience working with them.