The Risk in Sending Your Startup's Technology Offshore
April 6, 2017
Like what you see? Sign up for my Weekly Tech Leadership Newsletter:
When I wrote this in September, 2014 I was managing an offshore dev team for the first time, but almost every business I have worked with before and since has had some connection to an offshore engineering team. I've updated a couple points here, but mostly my advice is the same. Outsourcing overseas may seem "cheaper" than hiring a local developer, but be prepared for it.
To the non-technical startup founder, offshore outsourcing seems like a godsend. For pennies on the dollar, you can get programmers in India, Vietnam, South America, or the Ukraine to put together your software product in just a few short weeks, so why would you even try to go through getting a technical co-founder or raising funds to hire an engineer?
Every startup I've worked for has used offshore development teams to some extent and with varying degrees of success. It's true that outsourcing some work overseas can save you a ton of money, but if you're in an early stage startup, it might not be the best way to get your MVP together. In fact, it can be a huge risk that can impede the process of raising funds and hiring a permanent engineering team in the future.
Here are a few things to keep in mind if you're considering going the outsourced route:
1. It's extremely difficult to judge the quality of outsourced work without your own local engineer
It's not hard to find developers who can search the internet and hack together a piece of software that appears to work. You'd be amazed at some of the spaghetti-stringed crap I've seen that meets the business requirements for a project, but is almost unreadable. Unless you've got someone technical on your startup's team, you're not going to know what is going on under the hood of your app, and this can lead to a ton of problems down the road (more on that in a minute).
2. Prepare to work some odd hours and deal with communication issues
This might not be a big deal if you're used to working long hours at your startup, but it's something to keep in mind anyway, especially if you want to keep a sustainable schedule. Somebody needs to manage your overseas team, and if their workday is 12 hours ahead of yours it can be tricky.
Additionally, you'll need to be able to clearly communicate expectations and specs for your project in spite of language and cultural barriers. While most offshore contractors speak English, that doesn't mean they have the same communication style as we do here in America. For example, in India, it's impolite to say "no" or "I don't understand" to your superiors. This can obviously cause huge communication mismatches when outsourcing your product development, so it's important to know what your overseas developers are really saying.
3. Things will get lost when you transition to a permanent local team
Even if you have a good amount of overlap between hiring permanent local developers and your devs overseas, you won't have 100% efficiency during the transition period. If the expected pace of development doesn't allow for this slowdown, you're going to run into even bigger problems with your project.
4. Each feature can become a line item in your technical debt
"Technical debt" is a term that too few business people take seriously, but it's a huge red flag to engineers. By having loads of technical debt, you are admitting that you encouraged a pace that was not sustainable and you lack respect for the work that good engineers do.
This is fine for a minimum viable product, because most people plan on rebuilding much of that once they prove feasibility and raise funds, but if you find yourself still using an MVP laden with technical debt from a bad outsourced job for months (or years), you're likely wasting a ton of resources just patching things up every week instead of building a sustainable, well organized product.
5. Hiring and retaining local engineers could be more difficult
Nobody wants to come into a team with five overseas developers, two servers, and no version control, but I've been there before. If you get sucked into using a shabby outsourcing team, you're going to have a very hard time finding engineers who want to come in and deal with the cleanup.
Some tips for working with offshore talent
So how do you balance the need to create a low-cost MVP with the fact that offshore work adds extra risk to your already shaky business? You carefully choose a good contractor to work with and you learn to manage them well. Here are a few of the things I've learned while working with overseas developers at startups:
Use referrals and a sample assignment to find good team
The difference between a good overseas developer and a crappy one is huge, and the price may not be the best way to judge quality. Use a firm that is referred to you by someone technical whom you trust if possible. If not, be sure to give them some kind of small assignment to test their ability before you hire them full time. Don't just rely on code samples and resumes they send you as these are super easy to fake.
If at all possible, have a local engineer manage and oversee their work
Ideally you want someone you can trust who can also read and write code to help you manage your overseas team of developers. Contractors - especially those used to working for companies on a tight budget - rarely care about building sustainable projects, so it makes a huge difference if you have a technical leader to push them to do it right rather than just fast.
If not, watch for signs that the offshore team lacks planning or leadership
If you get a freelance developer or small team to work on your project, make sure a single individual on their end and a single individual on your end will serve as the point contact. It doesn't work to have three managers on your side giving each developer different projects at will. Planning and organization are even more critical when you give up control to an overseas tech team.
Force your outsourced team to write documentation
You can avoid a lot of trouble if you demand detailed documentation whenever a new feature or product is added. This might add some cost to your app up front, but believe me, it will eliminate enough hours of duplicate work that it will be well worth it.
Try to compartmentalize their projects; make organizational and architectural decisions at home
You may have a massive idea for a project, but you should really try to break it up into smaller, more digestible sub-projects before you pass it off to a contractor. I've found that offshore teams get overwhelmed, finer points get miscommunicated, and results are worse the more you give them to bite off at once.
Get demos early and often
Giving any group of developers a huge stack of requirements and 3 months to go build something is a recipe for disaster. Get your offshore team into a workflow where they give you a demo of a working (or at least partially working product) every one to two weeks. I can't tell you how many times I've heard founders get screwed by handing off their product to a team overseas only to check back in three months later to find that nothing was working as they expected.
Keep your features lean and don't fool yourself into thinking that your MVP will stand the test of time and traffic
So many non-technical people think that just because a project is finished and seems to work that it's "done," and they can wipe their hands of it forever. When it comes to software, this is a dangerous way of thinking as the problems you solve in your MVP will be worlds away from the problems you encounter at a scale of 100 thousand, 1 million, or 10 million users. Treat early versions of your product for what they are.
Budget time and money in your roadmap for the transition
Finally, you should plan to move more of your development in-house as you raise funding, and this means you'll need time and money in your budget for the transition. An overlap of 1 to 3 months is probably sufficient, but it could definitely go for longer depending on the complexity of your application.
Got other tips for outsourcing at a startup? Had a good or bad experience? Let me hear about it on Twitter.
Sign up to get the best Tech Leadership blog posts delivered to your inbox every week: