Over the years I've heard and read a lot of advice on how to get a technical co-founder. Having a mostly non-technical background myself, I've been facing the issues of having a "great" startup idea without having the technical chops to build it myself (although I have more programming experience than most business students).
In the last year or two a lot of the advice have centered around learning to code yourself. The logic is that with some coding skills of your own you'll be able to hack together an early version of your product and start getting some traction, making it easier to attract someone with enough technical experience to help you scale your product. The key here is traction. In a recent guest post over at Andrew Chen's blog, Elizabeth Yin shares the results of a not-so-scientific survey of more than a 100 developers, clearly showing that the most important thing developers are looking for when considering joining a startup as a technical founder is traction. Traction, traction, traction.
Not only are potential technical co-founders judging you primarily based on traction - the same goes for investors (particularly Angels and VCs). So by achieving traction you can either choose to get a technical co-founder (and perhaps continue bootstrapping) or you can raise a seed round and hire a technical lead. Or both take an investment and get a technical co-founder and use the money on other things that can help you scale quickly. In short, traction opens up a sea of opportunities.
But how to get traction without money, coding skills or a technical co-founder in the first place? An MVP (Minimum Viable Product, in short a the most basic product you can build to to help you validate assumptions and achieving product/market fit) is an important part of the Lean Startup methodology. However, it's a common misconception that you need to program to build an MVP, and to actually build a fully functional prototype of the product you have in mind to start validating your assumptions.
That is not the case.
Actually, after validating your earliest assumptions by talking to potential customers (usually assumptions related to the problem you're trying to solve), you can move on to building your first MVP. And by building I don't mean coding.
The main goal of your MVP is still learning and validation. It should demonstrate your UVP (Unique Value Proposition), nothing else. And in most cases you can set up some sort of semi-automatic system that at least simulates the functionality needed. Using a combination of Wufoo forms, Google Forms & Docs, Themeforest, Launchrock, Squarespace, Striking.ly, Wordpress, Tumblr, Mailchimp, IFTTT, Zapier, Kimono, Gmail/Google Apps and your phone you can set up a semi automatic prototype that will enable you to both accelerate your learning and eventually reach product/market fit without writing a single line of code.
There are plenty of examples of successful email-first startups and startups that did everything manually in the beginning and then gradually automated the process when they started to get traction (including AngelList, iDoneThis and Groupon).
Remember, you should be so ashamed of your MVP that you will throw it away eventually anyway. Making a "disposable MVP" is a good thing.
Prove that you can be more than the idea guy. It doesn't require programming.
PS: I am not saying it's a bad idea to learn some basic coding skills if you are aspiring to be a founder or a team member in a tech startup. It will help communication with the team and a little technical skills will make the strategy outlined above a little bit easier.
PPS: If you need a little guidance on how you can build a semi-automatic MVP for your startup or side-project specifically, reach out via twitter or e-mail and I'll be happy to help out.
PPPS: To get a weekly digest of the best startup advice from around the web directly in your inbox, check out StartupLetters.com.