3 ms·
So, you say you want to keep thing "as small as possible", bring 5 people on board, but still none of you is able to create something that the customers will pa
by crpatino 18y ago
So, you say you want to keep thing "as small as possible", bring 5 people on board, but still none of you is able to create something that the customers will pay for? I don't want to make any judgements, but seems like you do not appreciate the real value of the technical implementation. Your CEOs may have all the connections in the world, but if you cannot afford to have your product build, you still have nothing.
There should be nothing wrong with outsourcing the implementation details to a bunch of code monkeys in a developing country, but the point is that monkeys execute blindly. They are cheap because they do what you tell them to do (communication problems aside), no more but sometimes less. You cannot expect them to understand your problem and interpret a somewhat subjective description into a comprehensive requirements document. If they could do that, they would not be monkeys and would not want to work for peanuts.
If your resources are limited, you need to bring in at least one local reliable guy who wants to work for equity. His first job would be to build a rough prototype that will help your CEOs to harvest their network for additional cash (in the form of partnership, pre-sale money, whatever). The second job would be to lead a newly hired no-monkey team to build version 2.0, and provide the insight gained with version 1.0 to make this project successful.
<shameless_plug>
If you still want to cut some costs by hiring a foreign based team, I would recommend to pick a Latin American country... Mexico, Brazil, Argentina... We are not as cost effective as Asian developers, we have a huge advantage by being in about the same time zones. Mexico is Central and Mountain time, Central America is Atlantic I think. I am not sure about South America, but it is pretty close also.
Having access to the customer in real time pays big time when you are doing agile development. If you only share a few hours per day, or not at all, the cycle times will be in terms of months instead of weeks. You will have to rely more in Big-Design-Upfront style of development.
</shameless_plug>
- owkaye 18y ago"If you only share a few hours per day, or not at all, the cycle times will be in terms of months instead of weeks." Interesting theory but I find that just the opposite is true in my Asian outsourcing business ... I communicate with clients in the USA early in the morning and/or late in the evening. While these guys are sleeping in the USA my team writes code. The clients seem to enjoy waking up the next morning and seeing the results of the work we did while they were sleeping ... :)
- crpatino 18y agoHi owkaye, I think it all depends on how you organize things. If people can make progress on their own and just coordinate in few, well identified events, the more the better! At the end of day, all depends on the amount of coordination needed between people (which is exactly my point, you have to rely on written agreements and design upfront). If you think about it, it is not about whether things can be done or not. The selling point of "near shoring" is that people is closer to you in time and geography in case things go wrong. Most times they don't, and the client is only paying premium for her peace of mind. But when some major issue happens in your way, you are better off flying a senior member 3hours away than going through series of stressful meetings, offhours... over noisy lines... And let me emphasize this; most times, worst case don't happen at all. The reason this business exist is that it does not. It's all about risk management, like insurance companies.