There are so many anecdotal examples of bad experiences in this thread that I have to chime in with a counterexample.

I used to contract for a startup that was sold to Google a couple years ago for $350 million dollars.

In the beginning, it was just the two co-founders in the Valley and us developers, spread around the world. Later, when the company took VC funding, we helped to expand the engineering team with in-house developers as well (at the time of acquisition the total eng headcount was ~50 IIRC).

The product both took off like wildfire, grew, staid stable, and weathered some serious beatings on AWS just driven by the contractors. Even when there were several in-house teams, the remote ones were by far the most productive and e.g. drove 90 % of all the ops side of the service.

So, a couple of points:

* Retention/ownership: This has nothing to do with whether someone is an employee or a contractor. It's true that most outsourcing companies try to sell you just hired hands, but that's not all that's out there. You can find superb small developer houses that take more ownership in your product and code than any developer you can get in the Valley ever would. They're not 10x cheaper, but they're probably much better than any developer you can reasonably hire in the Valley at the moment, period.

We staid at the startup we contracted for from 2008 to 2013 and only left because Google doesn't do contractors, period. (This is a story of its own but I'm not comfortable telling it until a few more years have passed.) There were not a single employee that staid at the company for longer than us.

Employer shopping is much less pervasive outside US, so considering an employee a more long-term investment than a contractor is an illusion. Besides, you have the exact same means to keep a remote contractor happy as you have with an employee.

* Quality of code: This is a red herring IMO. You can choose whom you hire, even if they're remote. You have the same opportunities to check their level and productivity, and it's even easier to fire them if things don't work.

* "knowing what to build, not just how to build." Most of this isn't really related to remote vs in-house either. If the product is online, much of its clients are as well. I used to spend a shitload of time in the early days helping clients solve their issues from 10 timezones away. And often the clients were in the EU, when in-house people wouldn't have been available to help them.

* "you're still over there because you're not good enough for anyone to sponsor you for an H1B". Sorry, but I rather stay here with pure nature right off the door, 4 real seasons, and no rush, and produce the same (or probably more) output and value as a remote contractor. I might not make the same salary I would in the Valley, but it's not that far off if I contract for an American company. I also have much more flexibility to choose where I am at any given moment and how I structure my workdays. Plus, not all people hold money in quite as high a regard as people in the US do.

So, long story short: it's much more about who you get to work for you than employee vs. contractor. If you go for the cheapest code farm option, of course you're getting cheap quality. But you can also hire expert-level individual contractors or small teams where you know exactly what you're getting. They are not cheap, of course, but still less expensive than senior level employees in the Valley if you consider you can skip all the benefits and overhead.

And of course, at the moment they're probably better than what you can find in the Valley for any amount of money.