•February 27, 2020
When you as a business owner or leader consider creating custom software for your business, how do you decide to get it done?
Assuming you don’t have a software development team in-house, or even if you do and they’re too busy to get the job done, you’ll be outsourcing the job to another company. You know you’ll get better value from a team, but now you face another question. Do you hire an offshore team, or an onshore one?
Conventional thinking says offshore is the better choice, because it’s almost always cheaper, sometimes significantly. But is that really true?
The cost per hour for offshore developers is undeniably lower in many (if not most) cases. You might see something like an offshore developer being one-third the cost of an onshore one. Saving 66% or more per hour looks like a great deal on paper.
Look beyond the hourly rate, though. The rate per hour you pay is the top line comparison. You care more about the bottom line result. That’s where the hidden costs of offshoring can bite you.
Here are three big hidden costs to consider:
What’s the cost of delay, or wasted time? That depends on your business, but it’s certainly not zero.
What’s the cost of rework? That depends on what you paid the first time, but rework cost is usually a multiple, not a slight upward adjustment. It is extremely hard for a new development team to transition a disaster into a success without starting over.
The hidden costs are probably higher than the money you saved on the hourly rate. Maybe much, much higher.
We recently worked with a customer who gave us a direct comparison between our entirely onshore approach and another partner they worked with offshore (in South America).
The offshore team they hired created software for them in six months, at a cost of $50,000. Our customer wasn’t fully satisfied with the results and when they needed to scale the solution decided to have us essentially redo the project as “version 2”.
Our onshore team redid the software for them in a single month, at a cost of $45,000. Our version also included migrating all data from the version 1 system to the new one, integrating into their single-sign-on (SSO) platform, giving them almost entirely test-driven code (reducing the bugs they saw in the first launch), and adding more business features than in the original project scope.
That’s essentially the same project done by two different development shops. The onshore shop:
That is admittedly a single case, but why the difference?
You can find poor developers offshore or onshore. If you’re based in the U.S., though, you generally find people outside the United States, often in economically depressed areas of the world, who see software development as a path to success and knowingly or unknowingly try to take shortcuts to get there.
Your offshore developers might have academic experience writing software to a spec for a few “happy path” test cases. That’s not a system supporting many users over time, and it often shows. Most offshore developers simply don’t have experience supporting software in production for years. Sometimes you’ll even find developers who haven’t seen the full lifecycle of a single project — they’ve only added to existing codebases.
Do they really know the issues that come up once real people start using software? Do they know what can go wrong when you leave the happy path? Have they seen enough to be fully competent? You rarely find that kind of experience and expertise overseas (it’s actually rarer than you might think here in the U.S.), and you’ll pay for it as your system collapses under the weight of the real world.
At a more fundamental level, you also rarely find offshore teams using software development best practices. They may talk about them in their marketing materials, but they don’t use them.
Consider Test Driven Development (TDD). It’s one of the best ways to maintain design simplicity and project safety, but few developers here in the U.S. use it consistently, and even fewer overseas do. Not using best practices like this can lead to software that’s hard to maintain, and can’t grow and change with your business. You can do the math for yourself on the opportunity cost.
Cultural and language differences can have a large impact on your software development costs and success.
Working with a bunch of developers in a culture different from yours can mean you’ll face different interpretations of “quality”, different styles of handling (or not handling) conflict, or even different understandings about what misrepresentation means. It can get messy quickly, which can cost you time, which costs you money.
And that’s if everyone speaks English. What if they don’t? Then amp up the challenges again. If you have to spend a chunk of time in each meeting translating and making sure everybody nodding is in fact understanding things the same way, you’re going to move slower, see increased rework, and most likely end up paying more for your project.
When you work with developers overseas, it’s typical to get a “manager” for your project who is supposed to herd the cats, give you a single point of contact, and keep things on track. The idea is good, but the execution often falls short of the goal, to be generous.
You’ll often find yourself having to manage a remote team, probably in a wildly different time zone, with different work patterns and expectations. You thought managing local folks was hard!
We have had a couple of overseas clients ourselves, and in both cases we’ve made it work in different ways, whether that’s having them visit us for some “face time” and a well-coordinated project kick-off, or adjusting our schedules to allow for daily synchronization and no language barriers. That’s the kind of effort it takes to manage an offshore project well. Is your offshore team good at managing that way? If not, you’ll pay the price.
The economics of offshore software development aren’t nearly as compelling when you consider:
In fact, your costs can be much higher with the offshore approach.
If an offshore development shop claims they’ll save you 30%, 50%, maybe even 75%, of course you’d be excited. Who wouldn’t be?
If all you really need is a team to code up when you’ve already fully specified a relatively simple problem, offshoring might be a good option. But when you need a high degree of collaboration with a highly skilled team, and you add up all of the other costs we just talked about, most of the time the offshore claims aren’t really as good as they look.
