When You Should Hire a Dev Shop (other than "never")

I've always subscribed to the YCombinator / Paul Graham ideal that the best companies are built by founding teams of hackers, with perhaps a business guy or two (for example, someone with a strong business development, user flow or marketing background) thrown into the mix. But this often isn't the way things turn out. Many capable founders aren't developers, and I frequently meet with entrepreneurs that have taken a very different path. Most disturbingly, I've occasionally found myself agreeing with an entrepreneur's decision to hire a development shop to build their product. Sometimes, it just makes sense. But for every entrepreneur who has seriously considered the pluses and minuses of working with a dev shop in the context of the specificities of their business model, there are five who are hiring a dev shop because (a) they are lazy, (b) they don't know any better, or (c) all of the above.

The reasons why I am not a big fan of development shops are too numerous to go into here. In brief, startups succeed because there is strong alignment of interests among all parties, especially with the people who are actually building the product. Development shops who work for $100+/hour and take no equity are poor partners in a startup. They have zero incentive to create a quality product or understand the nuances needed to capture a market and please end users. But all that is for another post.

For you entrepreneurs who are considering working with a dev shop to build your beta, I've written a handy guide to help you decide whether or not to pull the trigger. Read the scenarios and give yourself points accordingly:

3 Points: You actually do not know any software developers. I doubt this is the case for anyone who is reading this blog, but if you really can't think of a single person to go to for introductions or advice, you may need to pay for it.

3 Points: You are pretty sure a LAMP stack is the pile of books on your coffee table, and Rails are what the Acela runs on. You probably aren't the best person to hire and manage a developer.

4 Points: Money is no object. Don't laugh. We've all seen projects like this.

4 Points: You are an exceptionally poor manager. As in you've been in management situations in the past, and you've been removed for being so incredibly bad.

4 Points: The development firm in question has some sort of special knowledge that is hard to find. Examples could be (a) experience building Facebook games under the new notification rules or (b) knowledge of how to build exceptionally secure e-commerce sites.

5 Points: You are developing software for government or major corporate clients. Being able to point at a specific development firm as "taking the responsibility" for the quality of the software is often reassuring to many government and corporate clients. I don't necessarily agree with this bias, but from an entrepreneur's perspective, it is what it is. Plus, most decent dev shops can point to at least a couple names of well-known previous clients.

5 Points: You have a development shop that will work for equity. This can be a good or a bad thing, and I should probably clarify it by adding "... and will actually get the job done in a timely fashion." But equity-based work solves the misalignment of interests -- there are just few dev shops willing to do it.

6 Points: You have a ridiculous project timeframe. For example, you need a beta built in four weeks. In this case, going through a hiring process is not an option. First, question why you need to get a beta out that fast. Then, really question why you need to get a beta out that fast. If your reasoning still makes sense, go hire a dev shop with the understanding that very little if any of the code that's written can be re-used.

-4 Points: You don't know exactly what you want. This doesn't necessarily mean that your spec is vague; typically, it just means that a product will likely have to go through several major modifications before the dog food starts getting eaten. Unless there's already a successful product out there that looks very similar to yours, you probably fit in this category. Iterating on a beta is a critical part of the startup lifecycle, and it is where the dev shop / entrepreneur relationship typically starts to sour.

Add all your points up. If you have more than 10 points, you can use a dev shop. If you don't, you should go hire a team of hackers and build it the right way.