Maybe I didn't communicate this clearly enough in the copy of the site, but my aim isn't to solely concentrate on ideas. The aim of the text will be to find common patterns between successful startups in their ideas as well as their execution that can be applied to other projects. I hope that clears things up a little bit.
Cool, I thought I'd give you a heads-up. Too many programmers make that mistake, so when I saw an idea-centered narrative in your .docx a red flag came up.
Yea I agree. I started by focusing on the idea just because it seemed like a logical first step, but that's by no means the extent of what I want to do with it.
I'm not sure which part of "patterns" or the book description suggests it's only about ideas, but in general, patterns can be about process or anything else. Where there are useful solutions to recurring problems, there are patterns worth mining and recording.
I might suggest the project just call these "startup patterns" as "design patterns" tends to make people think of technical coding or software architecture patterns. "startup patterns" is deliberately open-ended.
This is a common pitfall that plagues most developers who want to become entrepreneurs.
The idea is only one among several important factors that lead startups to success: timing, competitive advantage, finding the right product-market fit, identifying customer acquisition channels, devising creative ways to get the word out (aka viral loop), testing hypotheses early on, etc.
The number of startups with awesome ideas that have failed because their founders ignored all other variables is too large to ignore. Of course you don't hear about those as much, because (surprise surprise) the media feeds off success stories.
Please don't help propagate the idea myth.