Art & LogicWhile software development is not yet fully a commodity, it’s sadly headed in that directoin. However, for a software driven company, a friend of mine once said - you just don’t want to outsource your heart. Of course, you can’t always do heart surgery, and also it’s very expensive; sometimes you have to have someone else do it. But how to find the right set of resources to do it? What if you don’t have a bunch of them on hand? What if you don’t have a ton of cash on hand? What if you have a consumer facing product (where appearance and perception is super critical)? What if you’re building a pretty large piece of software? Of course, we have all of those things - and startups often do. So - we have outsourced a bunch. The questions of how to find the right resources came out of strategically breaking our product apart into components based on consumer interface. Meaning - we decided it was important to have our customer facing work built by a software vendor who had deep experience in music applications, a large portfolio in user experience and strong skills in complex usability issues. We also decided that the “backend” functionality - the guts of it - the online component, the model functions, could be done more cheaply offshore while still being highly functional and effective. Focal 3So we vetted a bunch of vendors and selected two - one on shore and one off shore. The vetting process went like this: 1. build a list of potential vendors who have domain expertise in the areas required 2. get proposals and cost estimates for the work 3. determine if they could work together 4. select from best of group 5. sign contracts. Here is what we’ve found: 1. It’s difficult to navigate the off/on shore two vendor path, but by no means impossible. It took about 2 months to hammer out our methodology, communications and release planning, but once it became normalized it’s no problem. 2. Requirements going off shore sometimes are difficult to confirm and typically are delivered at about 75% of what you spec’d (and you find it in the first few nightly builds). 3. It’s imperitive that the two vendors have a clear and consistent communications methodology and speak the same language (not English per se, but tech development language). 4. When vetting a vendor, unless you have a bunch of senior developers in house, you really need the top of the line that the vendor can find. You can’t settle for the vendor’s junior programmers. 5. This arrangement takes fairly significant management overhead - and constant constant communication and oversight. If you wait until delivery is done - you are doomed. But with proper management integration, it’s entirely possible. In many ways that’s no different than in house development - there is just more of it. And keep in mind - we get significantly higher performance from a vendor when we treat them like a partner or a valuable staff member in stead of a vendor - significantly. Note however, that managing vendors to a date is much like in house managing technical staff to a date. You can do it, but your quality and scope will dramatically suffer. In our case, we made the decision to allow date slippage (in some cases rather dramatically) in order to allow for higher quality delivery. Granted, we’re in a position of luxury to do that since we have not fully launched and don’t have rigerous customer expectations, but I’ll take it where I can get it. Lastly, for offshore, if you do partner stronly with a software vendor, we found it’s best to negotiate a fixed fee proposal. Don’t negotiate hard with them, let it go up a bit, they will go above and beyond if you don’t squash them and you’ll really really get tremendous value.

Originally published on WordPress on August 22, 2007. Migrated to this blog on May 29, 2025.