(This post was also published on the “Launching Tech Ventures” 2013 class blog, an HBS elective course taught by Jeff Bussgang)

When I initially started working on my first startup, FirstCrush (a personalized ecommerce wine subscription service), we had a team of two non-technical founders. 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 development resources. 

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:

• 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 development phase, because we ignored how the “little things” on the site 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.
• 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 as a new feature request, but this should’ve been thought through in the initial PRD process, not during QA.
• Clearly define your project and don’t assume that something should be common sense/unspoken rule. Thisis 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. 
• 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. 
• 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.  
• 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 one time when I camped out at our developer’s apartment to give him real-time product directions during QA. 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 it was done using the PSD image element, which meant that we would need a new PSD file to change the size of that box. Given that they know we did not have a full-time designer on staff, that should’ve not been the way they built the page. 

Sometimes using an outsourced development team can help you speed up your project because you can make parallel progress 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.