Show HN: Design Patterns for Startups

The current book narrative is very naive. The answer to the question "What Are the Elements of A Successful Startup?" is hardly in the idea alone.

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.

Why not call it Startup Patterns? "Design patterns" has a bad ring to it for a lot of hackers and startup people. "Startup patterns" is shorter, captures the basic idea, and is less constraining. Besides, most startups aren't designed.

Edit: I just noticed http://news.ycombinator.com/item?id=2746291. It must be obvious!

Edit 2: I would buy and read this book if it were done a certain way: if you avoid overgeneralizing or even interpreting what people do. If you could observe similar things that, say, three or more successful startups have done, and simply report them, that would be very interesting - much more interesting than trying to build any model or theory out of it. Basically, I'd like to read something like anthropological field work among successful startups; the more descriptive and less prescriptive the better. Practices that seem odd or irrelevant, and yet crop up several times, would be of particular interest. So would examples of things that successful startups do in opposite ways.

The reason I say this is that startups are not well understood, yet everybody seems to want to prematurely generalize them. These generalizations are not of much interest. More concrete observation, however, would be.

Edit 3: you should also find out what things startups do that they've always done from the beginning, versus what things got added later.

Interesting idea. Instead of a Word document you might want to consider writing the book in plain text, HTML or LaTeX. This will make it a lot easier to merge in changes from other contributors.

Rather than just diving into pattern descriptions, you may find it useful to agree on a corpus of successful startups and then identify specific things they've done well. Once you have a list of these things, you can start to cluster them together - pattern recognition!

This is roughly the process I've used in building pattern languages on the past. I'd also suggest you have a good idea of what you mean by success, because this is the filter through which you'll identify what's worked well. In other words, patterns should be opinionated. And that's going to be non-trivial (but tractable) in a project with multiple contributors.

This is clearly not the first open-source book, and not even the first one hosted on github. See https://github.com/schacon/gitbook for instance.

This is pretty cool - but it's hard to get to the book content itself. Maybe consider just publishing it as blog posts?

i would of much preferred you submit this when there was some content or more thought out. There's not even anything to look at. You should of at least maybe brainstormed out your ideas further with a table of contents or further list of ideas for content you intend to write or want people to contribute to. Theres nothing to show here.

Why not write it in Markdown, makes for easier reading on GitHub and provides the possibility to parse and publish later on.