It's crazy how many of this type of post are showing up everywhere. In the past couple weeks I've seen 4-5 posts on what founders did wrong or right with their companies.
It must be nice to be past all that and looking back on it to glean the lessons. Can't wait to get there.
Yes. Having "front lines" advice and anecdotes from actually building a startup are helpful even if they are only tidbits (i.e. cliff notes) of information.
It's probably the aftermath of the 05-07 startup boom and the weak economy. Startups are failing now, but since many of them didn't take VC, all we get are lots of postmortems. Also, solo entrepreneurs have fewer toes to step on and don't need to worry so much about airing their company's dirty laundry.
There was a similar boom in printed books after 2001 - anyone ever go to their library's business history section and read all the stories about dot-bomb flameouts? Now that just shows up on the web.
There have been a lot of posts about failed startups. This is about a successful startup and the problems it survived. Doing a diff between this and the other posts might prove useful.
One thing I notice is the failure stories always include problems with their toolset. This could-have-failed-but-didn't story does not. I think the "programming languages don't matter" crowd should pay attention.
This is probably selection bias. Everybody has problems with their tools, because all non-custom-made tools are compromises to fill the needs of multiple users. When you fail, there's always something where you can say "I wish we hadn't used this tool and had tried something better." While if you succeed, the tool headaches kinda fade into the background and just don't seem that important.
When I wrote up my postmortem (http://diffle-history.blogspot.com/), I wished I'd prototyped things out more. This was intended as a general statement about process and not an indictment of any particular toolset (though I still wouldn't use JSF for any Web2.0 site ;-)). I think tools matter, but doing your homework matters more, and the best tool usually depends on the job.
I noticed that a lot of this guy's points seemed to concern doing your homework up front and not feeling time-pressured to act immediately. That's something I noticed a lot in my startup: you always know far less than you think at the start, and it's worthwhile to validate your starting assumptions before you go off the deep end on them.
The one about thinking that they needed to move really fast reminds me of one of my favorite quotes, recounted in "The Dip" by Seth Godin:
"We knew that Google was going to get better every single day as we worked on it, and we knew that sooner or later, everyone was going to try it. So our feeling was that the later you tried it, the better it was for us because we'd made a better impression with better technology. So we were never in a big hurry to get you to use it today. Tomorrow would be better."
~Sergey Brin (cofounder Google)
That's a crazy mentality to have, and stands in such stark contrast to most of the frantic behavior of startups today.
But if it burns to slow (ie if your product does not generate the minimum amount of buzz to keep it alive) it will die. Entrepreneurs should make the difference between a slow burning fire and a slowly dying fire.
EDIT:
Thinking we had to spend more than we did
Too much resources handicaps more than not having enough. Give 3 coders a few thousand and they create Omnisio, which sells for millions. Give coders 15 millions and Omnisio will show up half as good and one year too late.
Placing my faith in consultants
Dude. I am not even going to talk about this one. Nowadays everybody claims to be a consultant.
It must be nice to be past all that and looking back on it to glean the lessons. Can't wait to get there.