Should I Use a Dev Shop? - Michael Seibel

A common question that we get at YC is: Is it okay to outsource the development of your initial product? The challenge here is that most founders who are not technical think that they have a problem that's worth solving, think they understand their customer really well, but don't have the ability to build the solution. More and more, the advice that these people are given is that instead of recruiting a technical co-founder, what they should do is use a dev shop to build the first version, get traction on the version, and then they can hire a CTO.

Now, I don't want to say this advice is incorrect because there are some companies that have been successful in doing this. The problem, though, is that it's too easy to focus on the companies that have done this well and not hear the stories about the companies who have done this poorly. Many, many, many times, I see emails from founders who've tried to do this path and it has failed.

So, I want to share a little bit about what that looks like when you're working with an outsourced dev shop. Oftentimes, it takes longer than you might think to get the first version of the MVP out. One, because you might not have a lot of experience in how long it will take to build software, and two, because that dev shop might be working on other projects or have other priorities.

To be honest, the person is not as motivated as they would be if they were a founder with a lot of equity in the product that they were building. This results in you spending more money than you might expect upfront. You might think it's going to cost you fifteen, twenty, or thirty thousand dollars for the first version, and oftentimes it can cost a lot more.

This is something that people find extremely frustrating, especially if they've raised a little bit of angel money and they're pouring all of it into the building of the initial product. The next challenge here is that oftentimes when you use an outsourced dev shop, it's actually harder to raise money. There are a lot of very good tech startup investors who do not want to invest in companies that are outsourcing development unless those companies are absolutely taken off and just growing ridiculously quickly, which is very rare.

The last thing that most people understand is that a lot of this work is actually thrown away. If you do happen to hire a developer, if the outsourced developer built it in a way that your person you hire doesn't agree with, oftentimes the solution that they will come up with is to rebuild. This is the kind of trap of working with an outsourced development shop to build your MVP.

If you want to build a tech startup—and by tech startup, of course, I mean a startup that's going to generate a lot of value for a lot of people, and you know, be a multi-billion dollar company and that wants to raise money from the venture capital world—you know that's what I'm focused on. There are lots of other situations where working with a dev shop is totally fine, but if you're in that narrow slice, this is the problem.

What makes this a trap is that it often doesn't look like a trap in the beginning. You often go from nothing being built before you have the dev shop to things happening once you have the dev shop. So you feel like you're making all this progress. Of course, you're spending money and it's taking longer, but you still feel like you're making progress until the first version's released.

You've spent that money and you realize that actually the solution that you built doesn't solve the problem, because it's rare that an MVP does. You need to start iterating, and now you start having to spend even more money and more time with the dev shop. Usually, this is when your funds run low and you realize, "Oh man, I can't make it. I'm not going to raise more money and I'm not able to do more iterations. My startup is gonna die."

Now, this is what you should be thinking about. I think the people who give this advice by using dev shops have their hearts in the right place, but what they're not quite understanding is that the vast majority of good early stage investors care more about whether you can build something than what you've built. They understand that at the point that they're investing, there's very little proof that you're going to be successful, and the thing that they're more interested in is: Can you iterate through multiple versions of your product until you can find a version that solves the problem that you want to solve?

Unfortunately, doing that with a dev shop takes longer and is far more expensive than doing that with a technical co-founder. There's kind of a misunderstanding that the early stage investor is actually looking for tons and tons of traction. Actually, they're looking for like tons of ability to build and iterate quickly. True early stage investors—not, you know, someone who does Series A—of course, Series A investors want traction.

If you don't fall into this trap, if you can recruit the technical co-founder, typically what ends up happening is you have to spend far less than you'd have to spend for that dev shop. You have a product that's released far faster, and you're much better set up to iterate the solution as you get feedback from your customers. So you get more done, spending less money in less time.

A lot of times, upfront, people think that finding a technical co-founder is too hard, so they give up and they go the dev shop route. What I would tell you is that so many companies fall into this trap that they should really reconsider whether or not spending that extra time recruiting a technical co-founder is going to be far more worth it than going with the dev shop.

Once again, I will reiterate: I'm not saying this applies in every situation, and there are certainly some companies that have launched their first version with a dev shop and have gone on to be successful. But in my experience, that is by far the exception, not the rule. So if you're going with a dev shop, you really should be worried about falling into this trap. Thank you.