Is Offshore Development A Good Idea?

Author: Ben Buie Ben Buie | 2/24/16

I recently passed my 1 year mark building Buink Web Development and thought it is about time to address one of my biggest competitors: offshore development. ūüôā

I say competitor, but I honestly don’t see it as that. Looking to the future, I¬†hope that offshore development is my friend, not my enemy. In fact, I don’t think you’ll still be alive in this industry in 20¬†years if you don’t learn to leverage offshore resources (unless offshore is also made obsolete by artificial intelligence, mu ha ha ha!).

I hope that offshore development is my friend, not my enemy.

That said, offshore development is not for everyone. In this article, I’ll share some of my experiences, list the pros, list the cons (including some solutions to counter the cons), and make some recommendations to help you make the most of your development dollars.

Here is how this article is broken out:

Pro: Come On Down, The Price Is Right

The low price of offshore development is the only “pro” that comes¬†to mind. There may be more, but I can’t think of any.

I’ve met and interviewed lots of developers (offshore and on) and, its true, most¬†offshore developer costs less than onshore¬†developers. No surprises there, in fact, some charge quite a bit less; for example, the lowest hourly rate I’ve seen is $9. That is cheap! Imagine, a highly skilled developer in a distant land making less than we pay people at McDonalds. Nine dollars, however, is unusual, the range I’ve seen is from $9-$60 and the average is about $25.

“The only ‘pro’ that comes¬†to mind is low price.”

These rates sound great, but are they too good to be true? They can be if you’re not careful.

Con: Their Timezone is Sleeping On the Job


When you’re trying to move at the speed of business, you’ll quickly realize that having a 5-12 hour delay in communication can really slow a project and even waste money. When you’re asleep, your developer is awake and vice versa.

I’ve seen the following two scenarios¬†many times. You wake up, rub your eyes open, grab your mobile phone, and review the developers¬†work from the night before. You realize they spent the whole day going down a “rabbit hole” of misunderstanding. You send an email clarifying something they did wrong. They wake up 12 hours later and respond with a question, which you don’t see for another 12 hours. The cycle continues! Work stops for multiple days¬†and time is lost.¬†Or, worse yet, they don’t clarify and spend another 8 hours going down another rabbit hole.

This cycle isn’t a product of the distance between lands. The internet and new technologies like Google Hangout, Slack, Trello, Basecamp, and others¬†have virtually eliminated the distance between two points on planet earth, but the timezone barrier¬†is still a serious issue.

I experienced this problem first hand with a developer not long ago, I’ll call him Victor. Our relationship was already on the rocks because he was hard to communicate with and he missed a small deadline. I gave him a second chance with a small project. I expected him to return the code in two hours, but when I woke up the next morning I found that he had billed 8 hours and still hadn’t delivered the code. He had all kinds of questions and I quickly realized he was trying to make changes on the wrong code base. No wonder he was confused about my instructions. Had we been on the same timezone, he could have easily reached out and¬†I could have followed up. Instead, he spent all night spinning his wheels.

“The timezone barrier¬†is still a serious issue”

The only solution I’ve found to fix this con¬†is to require the offshore developer to work in my¬†timezone. They won’t always do that and sometimes they’ll make promises they don’t keep, but if they do, it will save you a lot of time and money. If they don’t, just consider your true cost of offshore development at something like $40/hr and not the sticker price¬†of¬†$25/hr.

Con: Lost in Translation


As I’ve said in previous articles,¬†development specifications are hard to communicate EVEN¬†to native English typers and readers. When you add in the language barrier, you¬†may¬†find it impossible to communicate.

Notice, I specified¬†typing and not speaking. Speaking English is important, but if a developer can’t type quickly, they can’t code quickly. It sounds simple, but it is often¬†overlooked. Coding is typing; and typing in English¬†will always be harder for non-native speakers.

Reading is also critical. Your developer needs to be able to easily comprehend the project specifications. In addition, they’ll need good reading skills¬†to find help with bugs and features. When a developer hits a snag, a quick search of the internet often results in a solution. Most of the time,¬†someone has written an article about a feature you’re trying to implement. If a developer can’t read and understand quickly, they’ll likely be re-inventing the wheel with every new feature.

The truth is, I’ve never met an offshore developer that types and reads as well as a native English developer, and even some native developers struggle. ūüôā You just have to understand that this is going to be an issue. The question is, how much of an issue. Are they twice as slow? If so, the true cost of offshore development is looking to be closer to $80/hr.

“Coding is typing; and typing in English¬†will always be harder for non-native speakers.”

The best you¬†can do is try to asses their English skills and avoid those who have trouble. You’ll realize really quickly if a developer is avoiding email communication and opting for conversations via Skype instead. This is a red flag. I try¬†to force them to communicate everything via email and chat. If I notice some big grammar errors, the kind where you can’t even understand what they’re saying, then I usually don’t move forward.

In addition to screening their typing and reading skills, you must also realize that¬†they’re going to misunderstand some things and they’ll waste money in the first or second rabbit hole. As you can imagine, things get out of hand very quickly.

Con: Spaghetti Code


I have yet to work with an offshore developer whose¬†deliverables¬†were significantly more valuable than that¬†of an onshore¬†developer. I’m not saying they aren’t out there, but I’m still on the lookout. In my experience (which isn’t trivial) they aren’t much cheaper.

For example, I’ve talked about the first project I sent offshore¬†in earlier posts, but I’ll summarize it here again. It was a custom WordPress site. When I took over the code it was filled with all types of security flaws, they had hacked the WordPress core (making it impossible to update), and there was almost no structure/organization/architecture to the code. I’ve heard other people talk about “spaghetti code” and that is exactly what this looked like. From a user perspective, the site looked great, but from a developer perspective, it was a mess.

Even Victor, who I mentioned previously, delivered code (albeit late) that on the surface looked good but had to be re-coded in some aspects. Did his code add value to the project? Yes, but not without exception. Even though his rate was lower than my other onshore developers, his code ended up costing about the same or more.

“From a developer perspective, it was a mess.”

The only solution to this con is that you have to have an experienced developer review all offshore code. Just because it looks like it is working, doesn’t mean it is.

I’m sure I’ll mention this again, but I highly recommend you track code changes (via Git) and require all code changes to be packaged into small, feature related groups (called pull requests). ¬†These pull requests should be reviewed by an experienced developer you trust (like an onshore developer you hire as a lead).

Con: Stolen Code

stolen code

This con is only hearsay, in other words, I haven’t experienced it¬†myself. I include it here because I could totally see this being an issue.

I was out to lunch with a client recently, we’ll call him Zuck. He had¬†me act as a developer lead on a project with¬†a short timeline. I brought in several contractors to speed up the process. I mentioned to him that one of the developers was from Kiev, Ukraine and he said he was glad that I wasn’t working with anyone from India. He told me how he’d worked with several in the past and questions their ethics. “Sometimes,” he said, “they’ll just hack someone else’s code and package it up for you instead of developing it themselves.”

I didn’t dig into Zuck’s claim, but I take his word for it. I’m not saying¬†that India is somehow worse than anywhere else, but the rule of law isn’t the same in many other countries. The risk of getting sued by a client is drastically less for offshore developers than for us onshore. Offshore developers don’t operate under the same rules we do, and as a result, I can imagine there is less incentive to write honest code.

Luckily, the solution that prevents¬†spaghetti code¬†will also solve this con. Hire a developer lead like Zuck! I can’t stress it enough; you should require¬†developers to track code changes (via Git) and package code changes into small, feature related groups (called pull requests). Then, have each¬†pull request reviewed by an experienced developer.

Solution: Make Offshore Work

So, with only one pro and several cons, you may be wondering why I started this article hoping that offshore development would be my friend in the future. Well, you have to admit the price is very nice, if you can figure out how to prevent the cons.

Some of the cons are easier to solve than others. Timezone and communication issues are difficult, but through some trial and error with different offshore developers, most businesses can overcome these cons. Just be prepared to loose some time and money in the trial and error process.

It is, however, much harder to asses coding skills, both before hiring and while on the job, unless you are a developer yourself. For this reason, I don’t recommend overseas development for anyone who is not a developer. There are just too many phonies. There are too many overseas developers charging high rates and delivering substandard results.

If you’re not a developer, the only way I’d recommend you use overseas developers is if you hire an onshore lead developer you trust. This lead developer will review all code changes, review progress based on the number of hours worked, and make decisions about the effectiveness of overseas resources.

“Hire a developer lead like Zuck!”

I have several clients, including Zuck, who use my services to lead a team of developers. Some have existing developers they’ve worked with for a while and they want me to take over and make sure things are going as planned. Others want me use developers¬†I’ve worked with in the past. Either way, you’re better off letting me worry about timezone, communication, and skills assessment.

What do you think? I’m sure I missed something, so please share your comments below!

About The Author

Ben currently works as a senior developer and technical business consultant outside of Boulder, Colorado.

More about this author

About Buink

Buink Web Development is a development shop founded in 2009 by Ben Buie. For years, Ben built and modified web assets for clients in Utah. In 2011, he moved the company to Colorado and in 2015 he started taking on new clients full-time.

Buink’s Core Values:

  • Cost effective technology (with business strategy in mind)
  • Eloquent, maintainable code
  • Responsive¬†and transparent¬†communication
  • Quick project turn-around
  • Less code, less bugs
  • Start with responsive styles

Read more about¬†Buink’s core values

Read more about Buink

Connect with Buink

Connect with Buink via email, send us a message, or subscribe to our blog.