Very helpful - Like that first article as well, thank you. I wasn't attempting to bash the lean movement, though I have found it more difficult to implement with my own startup than I'd thought (emotions / fears find their way into the equation, spurring the batch death spiral). I just wanted to point out that there were other factors that will drive success now that the "secret" is out. Thanks again, and hopefully I can minimize the lessons I learn painfully.
Thanks! Very helpful. I've kept the user experience descriptions a bit vague as all of our user feedback has been from "lean" products - basically me emailing people with match suggestions with screen shots of shared mutual friends, then asking if they'd be interested in these people. We've had favorable response to that, but until the app is in our users hands I don't want to jump the gun. It's not yet - the stuff we can play around with works "amazing," but a full experience is not yet built so our users don't have it yet. I definitely could've been more specific, though.
On the video - great point. Wish we'd thought of that a bit earlier... The hope was to prove that we were legitimate. Gaining users for a dating site is not an easy proposition, and we should've focused more on what we can do for users than why we are viable.
I certainly tried to find a CTO before building a product - it's nearly impossible these days if you don't have funding, especially if you're founding your first startup.
So, I raised a small FAF round and outsourced my MVP to two awesome dev shops. Now I'm raising a second round of funding and can afford to bring on someone full-time. It's definitely not ideal, but it was the only way I could do it. I'm hoping the idea, the flexibility of the job, and the above average equity piece are intriguing to a potential CTO. Would be interested to hear suggestions on how to make this more attractive?
I can't really write that one yet, since I haven't been successful - I may be doing it all wrong. As to your second point, I understand developers are in the drivers seat. I was just trying to point out a few good ways to market yourself to a non-technical founder, since that's what I am and that's what I can speak to. I wasn't saying that you NEED to do this to get a job - you don't. Just saying that if you wanted to get the attention of a startup, this could be a good way to do it.
I made them so I could get something built quickly, and the development team I clicked with happened to build Ruby applications. I'd certainly be open to a change once I hire a CTO. I honestly don't know how hard it is to switch from one platform to the next, I assumed "very" so I looked for Ruby devs only. Maybe a bad assumption?
Oh, I'm with you on the "get a prototype up and running, using consultants" part. Definetely a good investment. But depending on how much work was poured into this, it's probably relatively trivial to re-implement. It is a minimally viable product after all, I hope?
There are three reasons why I would suggest that you don't emphasise the proficiency in Ruby. The first is, as mentioned above, that you're probably overestimating the effort required to switch platform at this point. The second is that a good programmer who just happens to have no/limited experience with Ruby will probably be able to adapt pretty fast, provided he has experience with similar technologies. By limiting your search to those that already know Ruby well, you're avoiding a lot of potential.
But the main reason why I think it's a bad idea, is because you are making decisions that I believe is the domain of a CTO to make. By doing so, you are sending a signal that you don't respect/trust him to make that decision. That is going to make the type of person you'd want onboard think twice about joining. I'm not suggesting that you actually feel this way (I don't know you, so I couldn't pass that judgement), but you should be aware of the way it will read to - at least some - people in your target demography.
Thanks for the comment - lot of good stuff in here. As for the languages piece, broad knowledge on languages definitely shows something, I agree. And I want to know what the applicant knows. I just meant that I could get a lot of that from the github account (as you point out), and that it doesn't need to be displayed in a resume. A resume telling me you know things is one thing, a github acct showing me you know things is another.
The links note is a good point. I was tailoring this towards my specific startup, and really early startups in general making their first "tech" hire. Once you've got a CTO or someone technical on staff, they'll handle the technical hiring and will understand the process and applicants far better than a non-technical founder ever will.
Appreciate the comment - I didn't mean it as fear mongering, just pointing out that the landscape will likely change over the next two years. Great developers will still be great developers and will have tons of job offers, I just imagine there will be a bit of a squeeze in the middle. I may be wrong. As for developers starting something on their own, I'm all for it if they've got the idea. They'll run into the same challenges any single founder will, but will definitely start from a better spot than a non-technical founder. I was more targeting this towards people who didn't have the idea yet and were looking to join something.
A) People who are paid to contribute to open source (either as part of their job or in some cases their whole job) and therefor have many commits.
B) People who write a little open source code on the weekends.
C) People who already work 60-80 hour weeks on proprietary/in house software and have other commitments for the rest of their time.
Also the "you need to contribute to open source to get a new job" thing has a perverse incentive for companies. If they know that having you contributing to open source makes it easier for you to either leave or demand a higher salary (because it is easier for you to get hired elsewhere). It is then in their interests to stop you doing it whenever possible.
