The risks of cheap developers
Published a month ago
Cheap doesn't always mean that you save money.
I live and work in the U.S., so this article is written from that perspective.
You're preparing to hire freelancers and looking at a dilemma. You can hire an expert developer in the US for $100/hour, a less experienced developer in the U.S. for $30/hour, or an overseas developer for $10/hour. You decide that "code is code, and the players are never going to see it anyway", and hire the overseas developer, thinking that at worst you'll have to pay a U.S. developer for a few hours of cleanup just before release. You're going to save a lot of money this way, right?
First, you should consider efficiency - an overseas developer might charge 1/10th as much but then take 15x as many hours to complete a task, so you end up paying more (and waiting a lot longer for the project to get finished). You can try to go with a fixed-price project, but those are the ones where the cheap developer (especially an overseas dev) is most likely to run months behind schedule, cut corners, or disappear from the face of the earth when they realize they bit off more than they can chew or a better offer comes along.
And here's the main thing - not all code is created equal. Bad code can be really, really bad. Look at it this way - imagine you hired someone to build you a house. When they're finished, it generally has the correct shape, all the doors, windows, and walls are in the correct places, and looks right on the outside, but it's made out of cardboard. It's going to fall apart the first time it rains. You're not going to be able to hire a contractor to fix this issue in a few hours - they're going to have to do a total rebuild.
The same is often true for game and app development. You can hire a cheap individual or team, and they might be able to put together a game that looks okay on the surface, but beneath the surface it's terrible engineered. It might have lots of bugs. It might run okay, but it's nearly impossible to make changes or add new features without breaking everything. It might be badly organized and difficult to understand or work with. You now have a mountain of technical debt - issues which will eventually need to be addressed, and the longer you put them off, the more time-consuming and expensive they'll be to fix.
I am frequently hired to overhaul projects which were originally developed by overseas teams. These are often riddled with severe engineering issues - code coupling, bad architecture, sloppy organization, total lack of optimization, use of deprecated Unity features, hacky custom solutions to do things they didn't know were built into Unity, etc. On the Editor side, you might have messy scenes, non-use or abuse of prefabs, messy project structure, nonsensical naming conventions, etc. These projects can require extensive or even complete rewrites of the entire codebase, and reconstruction of prefabs or scenes, before they are stable and easy to work with. The client may end up spending as much (or more) money on overhaul as they would have spent to have the game developed in the U.S. in the first place, meaning all the time and money they spent on the cheap overseas team was wasted.
Other common issues with overseas labor are timeliness, responsiveness, and honesty. Outsourced projects often fall behind schedule. The team may take days to respond to a message or ignore it completely. They might suddenly "forget" how to speak English when you ask them to do something they don't want to do. In some cases they'll milk you, billing you for far more hours than they actually spend working. In the worst case, they will take your money with no intention of ever completing the project.
That's not to say that all overseas teams will do a bad job. There are certainly some skilled developers in China, India, Ukraine, and other countries where code is commonly outsourced. Likewise, there are some developers in the U.S. who really don't know what they're doing. Do your research. Learn as much as you can about the freelancer/team before hiring them. Try to verify the items in their portfolio - if they say they worked on Call of Duty 17, contact Activision to see if they're telling the truth. If they say they were born in Portland but they have suspiciously bad grammar, ask them about their background to try to get an idea of whether they're really located in the U.S. After making a hire, ask for prototype builds on a regular basis, so that you can see how progress is going and make sure they know what they're doing. Host the project repository on your own GitHub or Bitbucket account so you can see the team's daily commits to the repo and monitor the quality of their code. Don't be afraid to let a team go if they aren't meeting your expectations - if you keep giving them another chance, they'll end up wasting a lot of your time and money.