I have a team of two (myself and my programmer). I can not program. Yesterday my programmer (he has built 40% of the website so far)said that in order to build a successful product and gain VC funding I need a tight group of programmers to put in a lot of time. To this point I have been able to find programmers who are interested in joining my team, however they are spread out across the northeast, do not know each other, and would work remotely. (Keep in mind I have no money). To explain further... He is basically backing out of the programming position and is advising me to find a "group of friends who love to program" to build my idea. He explains, that "having programmers that are programming together (in the same room) are going to produce a better product". Much like in the Social Network. I do agree with him however this makes things much more difficult. What do you guys think of all of that?
Sounds like your project is dead. You need to find a programmer who will stick around, and give it 1 year at least.
Lesson learned: work with people who can commit. And set that as an expectation. Also, I'd advise learning to program. It is now easier than ever and you can put prototypes and products together using Ruby pretty easily.
Once you have something to show, you can recruit more easily, and you can also carry on without programmers.
if you have a separated team you have a team. There are tons of huge (!) Open Source projects out there, which work very well and constructive. See OpenOffice, for example. Some of them are backed up by companies.
I suggest you to look at the Open Source development model. I don't suggest to open source your software, just look at the model at first.
Lets say people are spread all over the world. What are the problems?
You said, you are working with people from your the US. Assuming you are from the US too
and so on. You solve item 1 and 2. About 3, it is partially solved. US people work in a very similar kind compared to people from India. But of course there is some individual difference.
About 4, 5 and 6 you can look at the mentioned open source models:
and so on.
At least, you have to trust people somehow. You can see how much code is flowing into GitHub each day. But you cannot say that 5 lines of code is not enough. Sometimes it is. So you have somehow trust the people. On the other hand, programmers will claim about each other on the mailinglist if things are not in done they are waiting for. And of course they can help each other.
Motivating people is another problem. You need to give more than money. Ppl usually want to express their selves. This is, why Open Source works (or it is one reason) - if you follow the studies of Clary (1998), Omoto and Snyder (1995).
Please have in mind, if you do it with remote people you are working in a completely different way. Its definitely exciting and fun. It can be more constructive than having em in your office. But it also can fail - like every software project can fail. Most people do it the old fashioned way, but there are no reasons why it will not work with a new way.
If you ask me, don't let other people scare you - if you have only the chance to do it with remote people, try it. Until somebody comes up with proper statistics on that matter, all what has been said about remote vs. on site is pure imagination. Even when somebody has experience with both cases, it is just an individual experience. Of course, this is also true for my post.
And my experience - as an Open Source guy - is, it works well for me. And yes, I work remotely with other people on my start up. They are not working full time, the ball is rolling.
Hope my sight does help you a bit.
There are two things more important than having everyone together - having programmers who are skilled enough to handle your needs, and having programmers who are interested in what you're building. If you're making a relatively simple web application you may not need the top programmers, but finding a bunch of strangers on the internet who would like to help doesn't necessarily give you a team if they just want to help as a way to learn programming. If you can't program, and the current programmer you're working with isn't interested in continuing, it might be difficult to tell who can really do it.
Aside from that issue, how fast do you want to go? A lot of things can be built by 1-2 full-time programmers if you don't have a large investment to work with. Are you able to hire anyone, or do you just want them to work for equity? Both approaches have their good points; if you hire someone you get them dedicated to your business but it's not always easy to find good programmers who are looking for jobs. If you get someone working for equity that helps filter out people who aren't very interested and you may get someone very good without paying a high price, although you need to be careful to avoid people who want to "work for a big startup" and don't really have a passion for the product or the skills to implement it. Either way the smaller the team you need the better.
This is really a Q&A site, not a general discussion forum. I will try to help a little though...
I grew my business (builds web based systems that businesses subscribe to) for almost 4 years with not more than one person in the same location. We now have multiple people in different locations (generally grouping in two parts of the world) and have found that it is easier.
Having them spread out is not impossible, it's just not as easy as having them together.
Don't believe everything you see from Hollywood...;-)
Well I think he is right on the immediate statement, frequent communication is key when developing, face to face is far better than any other option ... but I don't think its the complete blocker or your only option if you manage it properly.
Finding funding doesn't have to depend on having a product, it helps but you can find funding to put the team together if you have a solid plan and good market potential at the far end.
If you have seperated team, then its better than no team and looking at it open source does pretty well with contributors from all over the world.
If you are heading down the seperated team approach then I think you need to spend time on the specification, screen by screen, function by function with a solid backend design that everyone can understand and agree on.
Breakup the work such that you can hand it out in discrete chunks. Most developers don't do this and just wade in somewhere and start coding, meaning they have to talk far more frequently (with lots of hand gestures), I suspect your lone coder is suffering from this at the moment ...
If you get a solid spec and plan out builds into "deliver something every 3 days to 2 weeks" you can work far more independantly. Also breaking down the project into bite sized chunks lets you manage the progress far better, seeing where people are stalling and identifying the points where developers do need to commuincate much sooner etc.