It’s been great watching the early stage startup community grow in the DC region over the past six to twelve months. Companies are getting funded, new ventures are being created every day, and on the whole, the entrepreneurs in the area no longer feel like lone wolves wandering around with no support network. As I’ve become heavily involved the mechanics of the community, through founding/co-founding ProudlyMadeInDC, DCTechMeetup, and Hackers/Founders, I’ve had a chance to speak with dozens of early stage companies. While the company may have an excellent founder, a great idea, and on occasion some seed funding, more often than not I hear the same thing:
“I’m looking for a technical co-founder.”
It’s a completely understandable situation to be in, putting myself in a non-technical persons shoes. You have a strong idea, (usually) a specific product roadmap, and a great marketing plan. All you need is someone to jam out some code in a weekend.
Limited Supply
The biggest issue in the market today is the extreme dearth of good, experienced developers. Even then, the good ones already have jobs, either at startups or large corporations with six-figure jobs and free cake once a month. And the more entrepreneurial types (referred to as hacker/founders) – most likely they’re already working on their own concept.
What do you offer?
A good developer knows their value in a startup. After all, they’re the ones who are actually building the product everyone is betting the farm on. In return for them getting payed a meager salary (or just equity), working 60+ hour weeks, and dealing with a plethora of product changes, users, system downtime, and all the other fun stuff with being the sole/primary developer, what do you bring to the table? What’s your track record? While they are building everything out, what are you doing? With them sinking so much sweat equity into cranking out code, what assurances do they have that you won’t just lose interest and walk away?
Here is some advice that I give out when I hear that line:
- Refine your product vision: If you still think that “MVP” is a sports term, spend a good amount of team going through the plethora of content related to Eric Ries’ lean startup methodology. A good chunk of the lean startup dogma is devoted to refining your product down to the absolute minimum necessary in order to gauge interest and, hopefully, revenue. When I’m handed a twenty page spec document split up into five phases, I always try and boil it down to the most basic, ugly, product that shows that it’s worth someones time continuing to build it out.
- Learn to code yourself: I’m sure I lost half the audience just by saying that. Some find too large a gap between someone who can architect software and someone who… tells them how to do it. But in truth, the difference is smaller than you’d expect. I’m not saying that you should expect to overnight become a master codesmith, but it’s certainly within your realm to learn enough Ruby on Rails (or PHP, Node, etc) to be able to crank out an initial version of what you’re trying to build. The documentation is plentiful, classes are always available, and due to the magic of open source software, there is a LOT of code that you can look at, learn from, and repurpose. Before you skip on this entirely, spend an hour starting off with http://hackety-hack.com/
- Hire a Team – So you’ve given up on coding it yourself. But if you have a very strong idea about what you’re looking to build, it’s certainly possible to get a decent product by hiring outside designers and developers (heaven help you if you think you don’t need a developer…). This should at least get you an initial prototype, and hiring a local developer to help support it and make changes can be done for a lower price.
Are you a developer?
OK, you might be reading this and happen to be one of the developers that everyone is looking for. If so, get in touch with me, right now. I’ll set you up.
