But if they would pay twice that (still at most half their normal cost) using a smaller higher quality company they could get a much better job done.
Anyone who has worked with the big vendors knows that the correlation between quality and price is very loose. The lowest cost provider is rarely great, but the high cost provider can also be selling you a lot of juniors.
But that probably works in most cases/places anyway.
But then the price mysteriously increases to the point where you might as well have hired them on-shore and you're not saving any money.
So, do you want to save money by offshoring everything, or do you want to get good people to actually do the real work that needs to be done?
They got where they are by doing what they are doing. Spending years on your project is something else.
I don't need to drag the building architects, master masons or master carpenters to help frame every wall of the house; ditto for code.
Probably why parent mentioned finding a smaller company. I don't know about the Indian outsourcing market specifically, but in many sectors it seems a few mid-sized companies are the best for this sort of thing.
Which also means you need to find the right one for your problem, your purchasing department won't be set up with them, and you won't be able to just order as much capacity as you want, so getting there is hard.
The Indian developers basically just transliterated the Windows code to Unix, and got it to compile. Then they shipped it. That's when the real problems started, and I was brought in.
Now, I've never claimed to be a developer. At the time, I was a consultant and Unix sysadmin, but the concept of "DevOps" had yet to be born.
What I could tell them was that, in 1996, basing your Unix implementation on Solaris 2.5 (not even Solaris 2.5.1) was a bad idea, because there was a whole host of things wrong with that ancient version of Solaris, and if they wanted to be on that platform then they needed to be on a much more modern version.
Secondly, threading on Unix at that time was ... problematic ... and that was true even on the most modern versions of Unix that were available at the time. Multi-process programming worked well, however. On Windows, the reverse was apparently true. So, naturally the outsourcing developers used threading, and they used threading on an ancient version of Unix that had about the worst possible implementation of threading. Oy.
Of course, learning these things at this stage didn't help Symantec. They had already outsourced their aircraft and gotten an Albatross back in return.
I did help them develop a testing regime that could relatively accurately simulate a real-world distribution of mail message sizes and types, with a real-world distribution of supposedly infected messages, and then beat the holy living crap out of the server trying to push that volume through as quickly as possible.
And I did get called back to teach a class on Unix to the lead QA team in Denver, so that they could try to support NAVIEG on Solaris 2.5.
But so far as I know, the consulting company I worked for never got called back to help them actually fix their design problems with the code, and I think that project probably died a pretty quick and vicious death.
Also, so far as I know, no one at Symantec ever again tried to develop or support any code that would run on any flavor of Unix or Unix-like OS.
edit: spelling
The whole problem is nobody can hope to spot the real "smaller, higher-quality companies" in that chaotic, offshoring-driven environment. Race-to-the-bottom is the equilibrium outcome.