Outsourcing has pluses and minuses. Additionally, there is the question of domestic outsourcing vs foreign outsourcing. Now all that said, what can you do to a

Outsourcing has pluses and minuses. Additionally, there is the question of domestic outsourcing vs foreign outsourcing. Now all that said, what can you do to appease the investor, but give over to him? I don't recommend it, but hiring on the "worse end" of the below list has surely poisoned past companies I've worked with against consultants. Additionally, you can say "sorry, not going to do it". You didn't make him CEO. At the same time, you will likely risk further investment from the fellow, but if he didn't specify before investing he was going to force this issue, well, then you can point that out you're feeling betrayed here suggesting this huge of a cultural change. Judicious use of outside development resources can improve a software company's morale. Pretty much all other uses tank it. I'm not poo pooing external consulting in all cases, however I am saying be realistic about what you're going to be dealing with when you hire someone at "1/5 the cost". I contend, if your business plan can be excuted by a bunch of external consultants, can't you instead build your company into a platform, and get third party developers to build on it instead, and make your money off licenses? Sorry about the unorganized nature of the following points: They're not connected enough to really summarize further. --------------------- With foreign outsourcing, you run into issues with cultural mismatch, as well as time zone issues. These are often huge issues for a company, and your relationship can get adversarial rather than team oriented relatively easy in that situation. Additionally, around the clock development is rarely the boon your investor is making it out to be. It is exceedingly hard to manage without sapping all the time of the people who are not on the same time zone as the majority of players . Large development teams basically in the same time zone are usually much more useful than the same size or smaller team spread around the time zones, as coordination get's more expensive off timezone. Additionally, foreign outsourced firms suffer from legal risks and IP risks (where they steal/take/copy) your code. Trade secrets, etc, are much harder to enforce cross borders. Lastly, with foreign outsourced employees, you lose key technologists every few years with no way to directly offer them better terms. Domestic outsourced employees are STILL problematic (Disclosure, I currently run a product development company, so some people consider us domestic outsourced employees). With Domestic outsourced employees, you face several challenges still. Firstly, if you gain enough control over their schedule or in-office work to make them like a real employee, you risk tax consequences. Secondly, you can still lose technologists, however you can often mitigate this with buyout provisions with the providers (See contract to perm offers). Thirdly, any external employees is a trade secret risk. If the secret is such is can be done in secret, no way to tell if the domestic external employee is developing something offsite with someone else using your secret. Domestic employees, whether external or internal, are vastly more reachable by phone (usually), and are definitely easier to reign in via law. Contracts are much more meaningful to someone you can easily sue the pants off of. But even though domestic employees have some slight advantages, they have some disadvantages too Most people who work domestically for per project hire, would make more in industry than they would working in a freelancing capacity. So the very qualified will still get job offers you will find hard to counter due to the structure of your hiring arrangement. Well, your "Individual chance of success" appears to vary widely depending on where you hire from. In the experience of teams I've worked with, and others I've talked to, here appears to be the lay of the land with foreign dev shops.(Please speak up with your own experiences; I'm going for full and complete rather than 100% nice; more experiences lead to more results): Indian: Often one of the cheaper options, but also the one most likely to staff your team with people who completely lie about their competency (or just don't know they're bad) with the given technologies. It is nice that everyone speaks English, but that's often not as important as the huge cultural mismatch in which frankness and the ability to say "I don't like this, change it" without lots of pain to the people at the company you're working with aren't really there. Lots of "work to the contract" type stuff here which means specification but avoids deep design goals. Many of the Indian development shops are "low prestige, low ability" workplaces for India, and once their employees gain real competency in a technology, they move to a more typical product company in India, leaving foreign consulting behind. There are some good experiences too, but they're highly depended on WHO you hire, and are often prefaced by "but these first guys we hired...." China: Many large companies have Chinese based consulting arms. They use them often especially in the embedded sphere. You do not often deal as directly with the development team in this country, but through an English speaking liaison. It's hard to get a cultural feel through that type of relationship, but in general, it feels more able to handle real criticism than the Indian experiences. Comments, names, etc are often understandable, but can be not, depending on the codebase. Things can get quite tied up in agreements here, then the agreements completely ignored (which I do not really understand why they spend so much time working on the agreements if they then know they're going to ignore them). Some companies even keep liasons up for daytime meetings with the US (others involve a late evening schedule to effectively meet). Costs are on average higher than India Success in this sphere appears to be about fiercely contained components that have detailed specifications. More likely to have high ability folks, but still much in the way of passing off low skill as high. Western Europe: Specfication stages seem to go much faster, however people in Western Europe don't feel like they work that many hours (probably true, but I don't know that much about European labor law). On top of the coordination, it makes for an interesting development. Similar skill variance as you see in North America, (with the good AND the bad). More realistic about schedules in my experience than their much lower cost peers in the developing world. Eastern Europe: This is the place you hear the most good about. There are plenty of low skill people trying to pass themselves off as high skill people, but if you find good companies, they often hire several good people and fire the lower skilled ones. Things like oDesk work out okay to hire individual devs, but the company based solutions are often far superior (in both time, individual additional management of employees, and even cost sometimes). The time zone being far out of sync is the biggest issue in this zone. Prices are all over the map though as far as work goes. I personally view that as a good thing, as you'd rather pay an amount in excess of the local norms if that gives you more team stability (for some projects). North American: This place is one of the most at hand. It feels like you're working with someone you could "make permenant any day", and like you really have recourse of law to deal with them in case of trouble. In reality, it's pretty hard to hire people who work for consulting/product dev companies away; they often enjoy the life they have more than the additional cash you can toss at them. Additionally, you get the entire spectrum of americans here, including the used cars salesmen types who slide along on charm rather than ability, or secretly farm out your stuff to yet a third dev house. You can most easily hire these folks on from a legal standpoint, but these folks are often in the higher cost spectrum (and if they're not, you need to ask why not). [I'm sure I've offended a few hacker news people, for that I apologize, but this is what I've learned working with people abroad and at home. Please join the discussion and add your experiences]