To me, the Number One issue is the quality of what you get back. Think about how most of those overseas operations work:
- Receive spec.
- Deliver code so that meets spec.
The first issue is generally with 1. You have to be able to define exactly what you need. Any deviation from your expectations and what they produce is the result of a bad spec. For example, you might have stipulated that the back end is SQL Server. And they code it to take advantage of SQL DataCenter....while you were thinking SQL Express. Be specific; very very specific.
Often times it takes almost as long to develop the spec as it would to code the thing in the first place. If you are a lone developer I'd encourage you to simply hire local talent that can roll with you.
The next issue is with number 2. These people are paid by their productivity, specifically, paid by meeting the spec in the quickest way possible.
If it is easier to copy / paste an existing page versus abstracting the logic in a reusable container, then they are going to copy / paste. Code quality, unless it's written in the spec, is not a concern.
I've run into numerous projects that started overseas whose code base was ludicrously large and buggy because the dev's simply don't have any concept of how to properly structure code for reuse. This isn't just an "overseas" issue but rather one due to low quality programmers. You will get exactly what you pay for.
For me, the only time I would consider outsourcing to another country is if I ultimately didn't care about code quality.
Having written the above, a great way of thinking about it is that the overseas guys are just like a bunch of computers. The more specific your instructions the more likely it is you will have a good outcome. Otherwise: Garbage In, Garbage Out.