Bad advice. Some people are just not meant to code. What do you expect them to accomplish with a book and 3 weeks of effort? A lot of junk.
My advice: go out an meet people.
True, you can't test coders, but you can validate how good they are through social validation. Good coders are respected.
Shoot high: find out who the great coders are. Pitch them your idea. That's going to be the challenging part. Find the one great coder who gets excited. The fact that you can pay them just removes a headhache down the road, but don't open with that. Close with it instead.
That's exactly what he expects them to accomplish: a lot of junk.
The thing is, junk that exists is much better at convincing top-notch coders to join than vaporware that doesn't. It shows them you're serious. More to the point, a good coder will instantly pick out a dozen ways in which your prototype sucks, and want to make them better. Because that's something virtually all top-notch software engineers I've met share: the urge to make something, once they've seen it, as good as it possibly could be. If they can't see it, they have nothing to work with. If they can, you might be able to snag them.
Everybody can't code, but everyone can make mockups. Use a tool like mockingbird (gomockingbird.com) and literally sketch out every single page/screen. When you make the mockups, you should be sure to know where every link/button goes, otherwise there's a page missing in your mockups!
Just this task alone would stop 95% of people with vague ideas. It also shows the coder that you have taken it as far as you reasonably can without learning to program.
A prototype is halfway. :-) All the way would be learning to code well enough that you could launch the product yourself.
If you can communicate your product vision in static mockups, that's great. But for most products, there's a world of difference between seeing something working - even if it's held together with string and wires and only works for the inputs you're demoing - and seeing a bunch of pictures.
As nostrademons said, I'm expecting junk code. But that's fine, because junk code still conveys the idea of what you're trying to create far better than the English language ever will. There's a reason why the YC application form asks for demos.
Pitch them your idea. That's going to be the challenging part. Find the one great coder who gets excited
Better to have two or more excited coders so that you can pick the best one; and your odds of having multiple coders excited by your startup are vastly higher if there's actually something for them to look at.
The only problem is, well, being able to pick the best one. From what I'm gathering, the OP is the not-software business type, and as such, he really doesn't have much of a metric to use to determine whether or not the person he decides on dragging into the whole mess as a co-founder will be up to snuff.
Worse yet, he's in an unfamiliar town, and as such, the trust metric he'll be using for people that he meets in SF is probably going to be out to lunch for a while until he can get his bearings down. This is the most troublesome part for the simple fact that it doesn't matter how much networking you do if you can't willingly place enough trust in the people you meet.
For now, to the OP, do everything: Network with people, kludge a project together, and do business development. Welcome to the club.
Comments
Bad advice. Some people are just not meant to code. What do you expect them to accomplish with a book and 3 weeks of effort? A lot of junk.
My advice: go out an meet people.
True, you can't test coders, but you can validate how good they are through social validation. Good coders are respected.
Shoot high: find out who the great coders are. Pitch them your idea. That's going to be the challenging part. Find the one great coder who gets excited. The fact that you can pay them just removes a headhache down the road, but don't open with that. Close with it instead.
That's exactly what he expects them to accomplish: a lot of junk.
The thing is, junk that exists is much better at convincing top-notch coders to join than vaporware that doesn't. It shows them you're serious. More to the point, a good coder will instantly pick out a dozen ways in which your prototype sucks, and want to make them better. Because that's something virtually all top-notch software engineers I've met share: the urge to make something, once they've seen it, as good as it possibly could be. If they can't see it, they have nothing to work with. If they can, you might be able to snag them.
Why not meet half way?
Everybody can't code, but everyone can make mockups. Use a tool like mockingbird (gomockingbird.com) and literally sketch out every single page/screen. When you make the mockups, you should be sure to know where every link/button goes, otherwise there's a page missing in your mockups!
Just this task alone would stop 95% of people with vague ideas. It also shows the coder that you have taken it as far as you reasonably can without learning to program.
A prototype is halfway. :-) All the way would be learning to code well enough that you could launch the product yourself.
If you can communicate your product vision in static mockups, that's great. But for most products, there's a world of difference between seeing something working - even if it's held together with string and wires and only works for the inputs you're demoing - and seeing a bunch of pictures.
As nostrademons said, I'm expecting junk code. But that's fine, because junk code still conveys the idea of what you're trying to create far better than the English language ever will. There's a reason why the YC application form asks for demos.
Pitch them your idea. That's going to be the challenging part. Find the one great coder who gets excited
Better to have two or more excited coders so that you can pick the best one; and your odds of having multiple coders excited by your startup are vastly higher if there's actually something for them to look at.
The only problem is, well, being able to pick the best one. From what I'm gathering, the OP is the not-software business type, and as such, he really doesn't have much of a metric to use to determine whether or not the person he decides on dragging into the whole mess as a co-founder will be up to snuff.
Worse yet, he's in an unfamiliar town, and as such, the trust metric he'll be using for people that he meets in SF is probably going to be out to lunch for a while until he can get his bearings down. This is the most troublesome part for the simple fact that it doesn't matter how much networking you do if you can't willingly place enough trust in the people you meet.
For now, to the OP, do everything: Network with people, kludge a project together, and do business development. Welcome to the club.