Lessons Learned from Working with an Outsourced Development Team

By Melody Koh

When I initially started working on my first startup, FirstCrush (a personalized ecommerce wine subscription service), we had a team of two founders who were not technical. We got far enough to conduct an MVP test on campus by putting together a WordPress site with PayPal integration so we could test people’s true willingness to pay, but we needed a real beta site that was polished enough to convey the trustworthiness of the service to test with the general population. We also needed a few key features to test our hypotheses around engagement and customers’ willingness to provide ratings of the wines they receive. 

After speaking with a few development shops that utilized a blended payment scheme of cash plus equity, we decided to go with Shop A in NYC. Although they seemed young and relatively less experienced compared to a few other options, they were much more affordable, were willing to do an all-equity deal (we did not have much cash so we thought this was the smart way to go – align incentives!), and seemed very enthusiastic about our project. They also pitched themselves as ex-entrepreneurs (which were true) so that they have more “value-add” beyond coding up our V1 website. 

We signed an agreement with the mutual understanding that it will be an all-equity deal, vested in tranches, with the last tranche fully-vested when the V1 site is officially complete. We tried to scope out what the definition of V1 is in a few bullet points and quickly went to work. Fast forward, we did get our V1 delivered and my experience working with the development team was generally positive. I learned a lot both as a first-time founder working with an outsourced team and as a first-time product manager, and here are some of the important learning:

1. Scope out EVERYTHING. All the details on the pages and how they flow – do not ignore even a tiny little button. When we first started communicating, we had the expectation that the V1 would be done by May 1^st. We did not launch our beta site until the last week of June. Why the delay? The scope of our V1 kept expanding as we continued with the PSD design process and the actual coding phase, because we ignored how the “little things” on the webpage would flow during the wireframing phase. Our QA process was prolonged because we inadequately used QA to get my product input into the build, which should’ve been done in step 1. 
   
   
1. Example: I was testing out a Facebook share button on the page and realized that we never designed the landing page for those who clicked on the shared link on Facebook. I would then sketch out the new landing page and file that into Pivotal Tracker (we used it to do project management/debugging tracking) as a new feature request, but this should’ve been developed in the initial PRD process, not during QA.
   
   
2. Clearly define your project and don’t assume something should be common sense/unspoken rule. This is especially true when it comes to working with an outsourced team and you’re under a project-based agreement. This is a hard thing for people who’ve never built web-based products before, because you just don’t know how much details is too much, and what might come back to bite you. If it’s not clearly defined in the contract, you have no way to get it done. 
1. Example: The first day the site went public to our mailing list, I got a call from an angel investor whom I met a few days ago. He claimed that the sign up page was not working, and it turned out that he was using IE as his browser. Yes I know Chrome is cool, but the reality is the majority of the Corporate America still uses IE. I immediately called our developer about the issue, and he pushed back saying “well making it render on IE is very involved, and we usually don’t do that for a V1 site…” – what? You would assume that “of course things need to work with IE and Firefox as well as with Chrome!” but yes you’d better spell it out in the agreement. I eventually got it fixed but I would rather not have that kind of ambiguity next time around. 
   
   
3. Don’t overly rely on the “equity” component to incentivize your outsourced team to act as founders/owners. Part of my oversight on #1 and #2 was partially a result of me trusting the development team as part of “us” because they were getting paid with our equity – if we don’t succeed, the equity is worth nothing, so the reasoning goes that we are completely aligned and I can trust their judgment to help me manage the development process to the best they could. This is true to certain degree but the incentive only goes so far. At the end of the day, if they’re a development shop/consultancy, they have multiple projects in the pipeline. Their bigger objective is to close one project so they can move onto the next one. If they’re so eager to close your project, they will rush through the wireframing/PRD process and take the shortcut when it comes to development. 
1. Example: The development team kept emphasizing the fact that they couldn’t start coding until they have the final PSDs from our designer. I did not understand why until I started camping at one of the developer’s apartment to work with him real-time to give him product directions. I was watching him code this color box on our homepage, and I realized that we might have to change its size if we want to alter the length of the text wrapped in it. However, that element was not coded in CSS to preserve flexibility, but instead he just used the PSD image element, which meant that we would need a new PSD file to change the size of that box. Given their understanding of our situation (no full-time designer on staff), that should’ve not been the way they built the page. 

Sometimes using an outsourced development team help you speed up your project because you can make dual progresses in your product and sales/business development while you recruit full-time engineer talent. However, be mindful about how your outsourced team is incentivized and carefully manage your and their expectations.