Startups in 13 Sentences
I have check marks next to 8 of these, and I'm working on a 9th (ironically, #9 -- "Get ramen profitable"); but I've broken 4 of these rules, and I don't regret it in the slightest.<p>Rule #1 -- Pick good cofounders.  I picked no cofounders, based largely on the fact that that I couldn't think of anyone who would be interested in joining me who wouldn't dramatically lower the average founder quality.  (Ok, that's being a bit facetious -- but I'm working in an area where domain knowledge is extremely important, so there are lots of wonderfully talented people who would be utterly useless to me as cofounders.)<p>Rule #2 -- Launch fast; and Rule #3 -- Let your idea evolve.  I started working on tarsnap in September 2006, and I didn't open tarsnap to the public until November 2008.  Over that time I ironed out some technical details behind the scenes, but the largest change in my idea was going from planning to charge $0.25/GB to actually charging $0.30/GB.  Since then, I've listened to my users and occasionally added an unplanned-for feature because of a request (or more often, several requests for the same thing from different people); but most of the ways that tarsnap has deviated from my original plan have simply been in the ordering of when I implemented which features.  The vision behind tarsnap, from 2.5 years ago -- an online snapshotted backup service with a tar front-end, a heavy emphasis on security, and a linear pricing model -- hasn't changed at all.<p>Rule #10 -- Avoid distractions.  I've remained as FreeBSD Security Officer while working on tarsnap, and I don't regret it in the slightest.  Yes, it has taken time away from tarsnap on occasion; however, it has also allowed me to further enhance my domain knowledge, and has brought many people to tarsnap (one person recently described tarsnap as being a backup system with "a good pedigree", which I'm presuming refers to my open source security background).<p>Now, for all that I've broken these rules without regrets, I still think that they're good rules -- in most cases.  But I think there should be a Rule #0: Realize that there are always exceptions, and understand why these rules are usually correct instead of applying them blindly.