Startup Lessons Learned -- Take it with a grain of salt

hahaha. this is great- I tried to post my own experience with this start-up (and in my opinion, citing the REAL problems) and was told to take the post down (later, with legal text) and now I see this post, trying to parody the one I wrote with things like 5. and 8. - shame. I might want to add though, that the author does not have the technical expertise to figure out who wrote how much code along with other (many) misrepresentations- otherwise, 8, while very sound and correct advice, might differ in terminology and he might have a better idea fitting his take into existing context written by PG and others.

Nonetheless, most of the advice is realistic and useful in the sense that the points raised are practical and might help structure your startup.

"Our biggest mistake in our startup was scrapping a prototype that was built in a certain framework for first PHP and then eventually Python/Django. ... This applies not just to the programming language or framework, but to hardware and software applications — keep costs low, use what you already know, and move on"

This is one that requires a large grain of salt. Switching technology may very well be compatible with "use what you already know" and "keep costs low". You can't switch key players in the middle and expect consistency in either quality or cost, which a lot of people think is possible. "You can’t afford to have a religion" works both ways: you can't have a religion based on what you perceive to the value of what you've already done either. I've come into a few projects after a not insignificant money was spent on "cheap" freelancers and contractors to "get the prototype up". Now all I'm supposed to do is add a few more features and polish it to take it to the next level or deploy it. This is often an impossible task, or one that will take longer or cost more than a rewrite because it merely does the prototypical features and wasn't built for expansion or even deployment. But people fear the "rewrite" because it sounds like you're starting over. Get the right people in early, use #8 when necessary, and #6, #7 will come easier (at least in terms of the technology).

I think the hard lesson I am learning is that you really can't afford to spend time arguing with co-founders about what should be included and what should not.

I think that every 2 person team has to designate one person as leader, and the other as adviser. Otherwise there are too many bruised egos and too much compromise.

Post was pretty good, but this link within the post was even better: http://venturehacks.com/articles/speed

Can really relate to #9 "Highs and Lows — Never give up".

One day I think "haha this is going to be BIG". Then the next day I think to myself it's an idiotic idea that will never make any money and is using too much traffic and I ought to just close it now before it uses more. Trying to average those feelings out over the days is quite hard - especially if you're a single founder.

I guess if you have co-founders, each founders highs and lows rarely coincide, so you're able to pick each other up.