Admittedly, given that I run an onshore development company, we can assume I am biased about this. But I also have some real-world experience that, all bias aside, can help you weigh the tradeoffs of onshore versus offshore software development.
First, let’s just state the obvious. The main reason to go offshore is to reduce your hourly labor costs. What’s not so obvious is that lower hourly costs do not always lead to lower total costs. Costs fall into two categories – planned and unplanned – each with their own set of considerations when viewed through the onshore/offshore lens.
Onshore vs. offshore software development: Planned costs
Software development is now dominated by Agile methods, where you involve potential users throughout the process, then iterate, optimize, and integrate small sections of code. It is assumed that you learn and improve as you code. You’re not just creating a rigid specification and handing it off to a coding team.
This makes is more difficult to estimate the cost of development in advance. For example, how can you estimate the number of iterations that will be caused by user input? How can you estimate how many integrations will be necessary?
Agile methods require close, daily collaboration, cooperation and – yes, this still matters – project management. Obviously this is more difficult when the developers are on another continent, in a different time zone that only shares a few working hours with onshore time zones.
Some offshore development companies have attempted to solve this problem by having onshore project managers who act as a go-between between the onshore client and the offshore development company. Assuming this doesn’t just add a layer of bureaucracy, and depending on the project manager, this can definitely help. I wouldn’t recommend going offshore without this type of onshore project management. But it also adds to the cost.
Onshore vs. offshore software development: Unplanned costs
All development projects are a gamble, because you’re creating something that isn’t successful unless and until your users decide that you’ve been successful. Obviously the less you pay means you are taking less of a gamble. Or so it seems.
A good number of the development projects we take on for clients are given to us after another firm or method didn’t work. It’s pretty common for a client to tell us that they went offshore because they thought they could get “the same program for one-third of the onshore cost.” The resulting code was not up to standard or didn’t meet specifications, and they had several do-overs. By the third iteration, they had spent as much or more than they would have spent onshore, and still didn’t have a product that was commercially and culturally viable. It brings to mind the old adage, “Never enough time to do it right, but always enough time to do it over.”
In these cases, the “cost” is in time spent and opportunities missed. Market windows only stay open for so long. Do-overs eat into those time frames, and also demoralize the team. The whole effort can get bogged down and become more of a gamble than originally anticipated.
Offshore software development can work if you have a very specific, well-documented product spec, strong quality control, and onshore project management that is well-led, organized, and experienced in working with offshore resources.
If your project requires a detailed business case and user functionality research, is going to be run using Agile methods and user testing, you’re going to be taking less of a gamble using an onshore development house.
For more information on selecting and working with developers for your upcoming app project, please download a guide for CEOs about creating great software from Applied Visions today.