Ask HN: Should I outsource development outside the US?

[endtime]

I am trying to launch a startup that requires development of a nontrivial web site. Right now the team is myself (CTO), two CEOs, legal counsel, and an accountant. We want to keep it as small as possible, and, as I don't have time to do the development myself, we are going to outsource it. My preference has been to use a US-based team, for a few reasons. I like the idea of being able to communicate with the developers in some situations, rather than (only) a manager. Also, we may want to establish some sort of long-term relationship for maintenance purposes (and possible new features later on). And, well...foreign development teams kind of have a slightly negative stereotype that I guess I was buying into without really thinking about it (I have no experience of my own to go on).

However, it turns out the cost of having this site built in the US may end up being a bit higher than we had expected, so I'm doing some rethinking. So my question is whether the above reasons for using a US-based team are legitimate or if I was just wrong. Should I consider teams not based in the US? If so, what are some red flags I should look out for? Any advice?

[coglethorpe]

Your startup sounds rather technical "a nontrivial web site," yet you have two CEOs, a lawyer and an accountant. In my opinion, you need to let go of at least one of the CEOs and outsource the lawyer and accountant until you have a need for them full time.

Why do you have two CEOs? Fortune 500 companies only have one. This sounds very much like an idea cooked up by some "business guys" who thought they'd farm the real work of a tech startup out to their buddy in IT. I've been there and I haven't seen it work.

In my opinion, there's a place for outsourced work, but it isn't when a startup is developing it's core technology assets. That requres heads down devlopment by a team of dedicated engineers for a period of months. That's exactly why YCombinator was set up. To deal with the minimal business setup and let the team just dig in for a quarter and see what happens.

[endtime → coglethorpe]

>Your startup sounds rather technical "a nontrivial web site," yet you have two CEOs, a lawyer and an accountant. In my opinion, you need to let go of at least one of the CEOs and outsource the lawyer and accountant until you have a need for them full time.

Well, a couple things. First, we're in the finance space. Second, both of the CEOs have a lot of important experience and connections. And the lawyer and accountant are kind of outsourced - they aren't doing this full time. They have both worked with one of the CEOs in the past.

The site is nontrivial in that it requires some serious initial development...but once built, it shouldn't require much maintenance. And it's nothing technically groundbreaking; there's just a lot of content management and user type stuff that needs to be put together. So it makes sense to us to hire a team to build it.

[brc → endtime]

"but once built, it shouldn't require much maintenance."

I think you need some technically proficient co-founders to really understand what is involved in iterating towards a successful project. Successful websites aren't like office buildings where you build it and then move the furniture about yourself. You'll need fulltime development staff to reach your goals.

[coglethorpe → endtime]

I guess if I was in your shoes, I'd hire a small team of developers (3?) to do the initial build. Pay them with a combination of cash and equity. If this is in the finance space, you should have some funding or be able to get some.

[endtime → coglethorpe]

We have funding. :) But we still want to keep costs reasonable as much as possible.

And hiring a small team might make sense...but we don't have office space right now, and we're actually spread across the country a bit (I'm in California, one person is in Florida, the rest are in New York). So most of the situations in which we hire a small team end up adding more overhead than they're worth, unless I'm not thinking of something.

[sarvesh → endtime]

Unless you have your requirements down to the smallest detail, which is rare, it will probably cost you a lot more to have developers spread out in different parts of the country. You are at a phase where you want rapid prototyping to discover what your real requirements are. Outsouring at this stage is a bad idea.

[crpatino]

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 → crpatino]

"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 → owkaye]

Hi 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.

[david927]

I'm a big proponent of this; I guess because it's worked well for me. You can get spectacular results for much less, but you have to know what to watch out for.

For example, you should have (at least) one person in the off-site location who really 'gets' what you're doing. This person should be the CTO/Architect, if possible. Development should be agile. You need to know if it's ever going off-course as soon as possible. Communication can't be understated; have daily scrums, for example.

There's a lot more. Feel free to write me. My email is in my profile.

[ibsulon]

If you are going to go with outsourcing...

I would suggest bringing on an enterprise architect with experience in outsourcing to design the system and have a full understanding of what is going on. Preferably, this individual would have a group he has worked with already.

But given the constraints you mention, I'd suggest getting three developers in your area who prefer to telecommute and meet for coffee twice a week.

[quilby]

This has been discussed many times. See:

http://searchyc.com/ask+outsource

[noodle]

executive summary: you get what you pay for. if you want a quality product, you'll pay for that quality product in some form or another. cutting corners now will compound costs later.