I guarantee whatever the company saved from hiring this offshore team, they lost it all and more in all the rework. Expensive consultants spent cleaning up all the lost on-shore work, cleaning up all the projects that just turned into expenses because we had to throw absolutely everything away. All the time we spent waiting for them to rebuild things. So don’t do it. Not even once.
This story means no more outsourcing overseas, right? Not quite. Let’s see what we can learn from this. Software development and offshore teams are an industry norm. At the same time, this practice also gets a bad reputation. When you say offshore team, many people think ‘low quality’ and ‘difficult to work with’. Is this reputation deserved?
There are many successful offshore projects; in fact, most are. But there’s no denying that it carries added risk. The reward is you can get your product at a fraction of the cost of hiring locally. For a startup, offshoring could be the only way you get a working prototype. The risk is, choose the wrong team and all that money you wanted to save?
You’re gonna lose it, and more. Case in point, u/apache_spork’s experience here on the sysadmin subreddit. I’ve already read it, and I feel really sorry for their team. Everything their management did was a textbook case of what NOT to do when hiring overseas teams. It’s quite tragic, but I can’t help but laugh at some of the stuff shared.
Hiring an offshore team is a really viable option if you approach it with the right mindset. Quick Disclaimer: Upstack Studio is not affiliated in any way with the parties in this story. Whether real or fictional, we think it represents a real-world situation often faced by inexperienced founders. And any commentary is meant to be educational, not to condemn.
Here are some common reasons an offshore software project fails:
Dream job burns to the ground after an offshore team got involved. Landed dream job. Extremely fast-growing established company moving to the cloud. Great pay, great budget, good benefits. Fast pace, and all the changes from merger start to cause churn.
Company starts making heavy use of consultants and short-term contracts. Nothing wrong with that. The company is in a growth phase, so freelancers are more scalable than getting permanent staff. But this part already indicates it’s not gonna end well.
Company gets a large Indian offshore team because they’re essentially the cheapest temporary labor you can get, and you can easily scale up your team up and down based on demand. Please understand that the fact that the offshore team was from India has nothing to do with the issue here. There are good teams in India. There are bad teams in India. It’s the same in any country.
And the way the management hired developers, they would have gotten a bad team no matter where they looked. Yes, you outsource overseas to cut costs. But what you’re really doing is trying to get high-quality work at the lowest possible price. If the quality isn’t there, it’s not even worth considering. But that doesn’t seem to be what Apache’s management did.
For them, it wasn’t a matter of cutting costs; it was about cutting corners. Right from the start, they hired purely based on price, and they immediately ran into issues. All senior developers and mid-level developers were junior developers I wouldn’t trust with training wheels. We would instantly get more guys, but they were all in a state where they wouldn’t be ready without months of training.
For the ones I tried to train enough to be competent enough to do the job, once they start to look like they can take on the work independently, they find another job. The offshore team was treating it like an internship. But it tells you that they were probably being underpaid even by their cost of living standards. The moment they knew they could get a fairer wage, they left.
It’s unprofessional, but so is underpaying people. And if we keep scrolling, we start to see issues with the work. Multi-cloud is not always better than single cloud. Our friend Apache here clearly has a technical background. He knew what the offshore developers were doing wrong and he could give advice. It’s just they either didn’t understand it or outright ignored it.
I can’t imagine how you’d deal with this as a non-tech founder. Where do you even start? The people you’re relying on for technical knowledge don’t have the right technical knowledge. I hope that doesn’t scare you away from going offshore, but I hope it scares you into doing your due diligence.
So a bunch more on low-quality work. Here, let’s get to the part about poor communication. They assumed all dates were UTC for thousands and thousands of tables and data sets. If there was a time zone on a date, they would delete it so everything was in their standard format. This part screams poor internal communications.
There must have been at least one project manager from their side who would deal with Apache’s team directly. Whoever they were, they must have known this was an international client based in a different time zone. But somehow, I think that information wasn’t cascaded down to the actual developers. It’s not that surprising if you remember that they were facing staff turnover issues, so there were probably lots of new hires just shoved into work without any briefing.
India is a big country, so their team might have been really geographically dispersed. It can definitely become a bottleneck. And if we look just a bit further down, we see another communication issue that tells me yes, this agency was bleeding talent. Offshore started doing things like everyone responding from a mailing list. One guy committing all the code. Slowly our visibility into things decreased, and our repeated complaints didn’t change their behavior.
You couldn’t really tell who you were talking to, and who was doing the work. I suspect they were doing this because we had a huge contract, and they were only giving us the minimal amount of people humanly possible. Their staff were probably leaving faster than they could hire replacements, and they had to hide what was going on.
After assigning the work, they’d spend a week on the analysis phase, then say they have a blocker on clarifying or some such thing. It would be weeks before you get one line of code, and then they still needed several rounds of testing before you got garbage. This would go into raising a defect, analysis, and implementation phase. An offshore version of agile. That’s not fair. Don’t associate Agile with this. These developers don’t even deserve to use the word ‘Agile’.
If it takes you weeks to write a line of code, you’re barely even a developer. Management should never have hired this agency. But fine, hiring mistakes happen. Why were they not fired in one month? This is probably the saddest part: There were many untold horrors that would surely bubble up, and train wrecks occurred on the customer side just waiting to be discovered.
We can all agree that Apache’s management messed up big time. We can all agree the developers were not the best, to put it kindly. But when you knowingly release bad quality work to your clients and customers, Apache’s team became just like the nightmare offshore team, but to their own direct clients.
This story shows how decisions made with the wrong priorities can put everyone in a bad spot. With software development, you get what you pay for. Apache’s company tried to pay next to nothing, and that’s pretty much what they got. This story happened four years ago, and I sincerely hope Apache’s gone on to have a great career. Meanwhile, for the rest of us, it’s a really valuable lesson.
Nothing wrong with outsourcing overseas, but vet your choices carefully:
1. Nothing should ever compromise quality.
2. Ask to meet your app developers, including mobile app developers, to see if there might be communication or timezone barriers.
3. When you meet them, ask them questions about their agency and work processes. We’ve got a cheatsheet for you to easily send out. It’s got all the relevant questions to help you evaluate a software developer’s credibility.
4. Whatever they say at the start, make sure they stay consistent throughout the project. Don’t be afraid to remind them of what they promised.
If you do those things, you’ll probably never need to vent your frustration on a subreddit like poor Apache. For app developers, this advice is crucial to ensuring your projects run smoothly and successfully. Whether you need software developers or mobile app developers, following these guidelines will help ensure your project’s success.
