Responding to previous comments, I would advise against using an Indian firm for a startup. I think overseas firms can do well when assigned routine work, like putting in a CMS where all the requirements are straightforward, or handling inventory and accounting. For exceptional circumstances (which is what a startup faces) you want people who can meet everyday in the same room.
Geographical distance is a major problem for small startups.
I worked on a project last year where the project manager was thrilled at the idea that he could hire Indian programmers for $10 an hour. I was in New York City, we had another programmer in North Carolina and another in Europe. The "CEO" was an investor who attended meetings 2 or 3 times a month. The project manager was basically the CEO, but he had no real power, since everything needed to be decided by the CEO. Myself and the project manager would have 3 hour conversations and decide on something, but then need to explain it to the CEO, whom we only saw a few times a month.
The project went nowhere.
From this, I conclude, it is best to have small team working in the same room, when doing a startup.
The team in India was unusually bad. Every time they committed code to Subversion, something broke and I would have to fix it.
Duh, You are right; if someone wants to hire lots of cheap Indian labour for $10 an hour, you will get bad programmers. I think, at that rate you will get bad programmers anywhere in the world.
I am building (http://solaro.com) and we just launched our application out of beta. Development happens from India and surely there are kinks and warts, but at the end of day it works.
I think there are lot of things people get wrong when doing outsourcing:
1. Going cheap. Good programmers are costly. In India you will have to fight with Google, Amazon, Microsoft, Adobe and likes for the talent, you can't pay cheap and expect good programmers.So, please do not come to India, if goal is to stay cheap.
2. Not involving the team. You will have to bring down your walls and involve everyone intellectually. This is real, if people aren't involved with the product, you are going to get crappy result. I am saying nothing new, but what already Jim McCarthy said in Dynamics of software development. But this is more true for projects, where your team is spread across different geographical locations.
3. Iterate. Short iterations, deliver, continuous integration and continuous deployment. Do not sleep on the project.
4. Small teams, do not build a large team just because it is cheap. I know I am saying the obvious here, but I have seen people getting it wrong too often.
5. If the client (or product owner) is located in different geographical location, he/she has to work harder than everyone else.
Geographical distance is a major problem for small startups.
I worked on a project last year where the project manager was thrilled at the idea that he could hire Indian programmers for $10 an hour. I was in New York City, we had another programmer in North Carolina and another in Europe. The "CEO" was an investor who attended meetings 2 or 3 times a month. The project manager was basically the CEO, but he had no real power, since everything needed to be decided by the CEO. Myself and the project manager would have 3 hour conversations and decide on something, but then need to explain it to the CEO, whom we only saw a few times a month.
The project went nowhere.
From this, I conclude, it is best to have small team working in the same room, when doing a startup.
The team in India was unusually bad. Every time they committed code to Subversion, something broke and I would have to fix it.