Should I use a dev shop?

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 that 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, 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, many times I get emails from founders who've tried to do this path and has failed. And 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 the software, And two, because that dev shop might be working on other projects or have other priorities.

And, I mean, 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. So you might think it's going to cost you $15,000 20 thousand dollars 30 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 in the building of their initial product.

The next challenge here is that oftentimes when you use an outsourced dev shop, it's actually harder to raise money because 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 because if you do happen to hire a developer, if the outsourced developer builds 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.

So 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, mean 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. That's what I'm focused on.

There are lots of other situations where working with DevShop 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 Devshop to things happening once you have the Devshop. So you feel like you're making all this progress.

And, 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, you realize that actually the solution that you built doesn't solve the problem because it it's rare that an MVP does, and you need to start iterating.

And now you start having to spend even more money and more time with the dev shop. And 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 going able to do more iterations. My startup is going to die. Now, is what you should be thinking about.

I think the people who give this advice about using Dev Shops, their heart's 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? And unfortunately, doing that with a dev shop takes longer and is far more expensive than doing that with a technical co founder.

So there's kind of a misunderstanding that the early stage investor is actually looking for tons and tons of traction and actually they're looking for tons of ability to build and iterate quickly. True early stage investor, not, you know, someone who does series A's. Of course, series A investors want traction.

If you don't fall in 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 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.

And so 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 in the end is going to be far more worth it than going with the dev shop.

Once again, want to reiterate, I'm not saying this applies in every situation and there are certainly some companies that have bought their first version of 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.