Content originally written by Jeremiah Lee Cohick and published on the awe.sm blog

Shortly after awe.sm’s series A funding, we were eager to begin building the larger products we envisioned. There were only 3 of us writing code at the time and we needed to rapidly expand our development bandwidth. So while we looked for talented engineers to join our team full-time, we evaluated several web application development companies to help us get a head-start in parallel.

We asked our investors and other startups for referrals. We also looked on GitHub to find contributors to the open source tools we were planning to use. After narrowing the list to three companies, we reached out and interviewed each company.

Our selection criteria:

• Expertise: We had decided to use Backbone.js. The framework has few opinions on The Right Way of doing things, so we wanted a team that had opinions about using it in a large application and could justify them with their experiences.
• Cost: We expected a rate of $100–$150 / hour and hoped to negotiate down by agreeing to a monthly minimum and a 3–6 month engagement.
• Similar engineering ideologies: No CoffeeScript. Appreciation of Douglas Crockford‘s opinions. Use of native DOM methods over jQuery when possible. Only performant uses of LESS.
• Size of team: We wanted a team, not a single developer. This is the “hit by a bus” factor: would we have to start over if the lead developer suddenly became unavailable? We also liked the option to have additional engineers working on self-contained features in parallel with primary development.
• Pair programming, if any, only when necessary: In our opinion, the primary beneficiaries of pair programming are the apprentice, who’s gaining experience, and the company employing the engineers, which is creating a sustainable workforce. The benefits of pair programming to awe.sm would be minimal. That said, pair programming is useful when beginning large features, as it allows engineers to have a common understanding of integration considerations when working independently on features. We wanted a team that had this pragmatic approach.
• Direct access to engineers who were fluent English speakers within 3 timezones of San Francisco: We wanted a company that felt like an extension of our team, not a middle manager that proxied information asynchronously. We knew that we were going to build a product with complex data handling and GUI interactions. The ability to communicate by text and video chat throughout the workday would allow us to most effectively discuss features, bugs, and details we hadn’t considered.
• Previous customers we could interview candidly about their experiences: We were making a big investment and needed to move quickly. We wanted to know the team’s strengths and weaknesses upfront.

After the interviews and contract negotiation, awe.sm chose Quick Left. I traveled to Boulder, CO to kick off the project with them. We discussed the features, interactions, and motivations for every detail in the spec and wireframes. They broke the user stories down in Pivotal Tracker, which awe.sm also used. With the stories agreed upon, I returned to San Francisco.

We used Campfire for text chat and Skype for video chat daily. I was able to review their commits in GitHub. We prioritized stories and bugs in Pivotal Tracker weekly. Six months and 70,000 lines of JavaScript later, the new awe.sm was ready for beta testers.

I learned a few things along the way and I’d do some things differently in the future:

• Text chat is great, but be quick to take conversations to video chat. We seem to express ourselves better with speech than text. Screen sharing is also useful.
• Gigantic specs with every minor detail in a single document don’t get used. Break each section of the application into a separate document. Kick off each section with a video chat. The spec should contain wireframes with relevant interactions, features within the context of user flows, and any forgettable specific technical details. If developers understand why features are valuable to the user and how the user will interact with them, many of the details don’t need to be documented. You spend less time writing specs and developers can more easily find the details they need to reference. Help the team understand your goals and they’ll make smart decisions.
• Expect fluctuations in workload when dealing with multiple parties. awe.sm was responsible for delivering additional server-side capabilities for the front-end application Quick Left was building. We also used another contractor for the visual design. Every interdependency increases the probability of lulls and spikes in workload.
• Managing external teams takes more time than you think. Coordinating assets, testing, and dealing with unknown unknowns is a full time job.

By the time our application launched, awe.sm had hired a front-end team. Quick Left trained our engineers on Backbone.js and helped us transition to internal development. Quick Left gave us a solid technical foundation for the new product they helped launch that we’re now rapidly iterating upon. Their quality of code matched awe.sm’s own high standard and their expertise helped us make the right engineering decisions for this product.

By working with Quick Left, awe.sm was able to take the time it needed to hire the right people and launch a new product without hampering the development of its existing products. When time-to-market is important and you have the cash available, using an outside development team can be a useful strategy for startups.