I have read several different takes on "Worse Is Better" on the Web, as well as Gabriel's book, Patterns of Software, and generally think it is a good way of developing useful software. It is too bad though that he didn't give it another name; the bad part about the phrase is how lazy or careless programmers use it to excuse their laziness and carelessness.

IMO, the "worse-is-better" approach is especially applicable to startups in the sense that during its first few iterations, you (the founders) don't know exactly what-to-build. Hence, the definition of "completeness" in the scope of your product is fuzzy at best.

Once the idea of "completeness" is crystallized (based on listening to what people want), I think that's when it's a good idea to build it right.

By "building it right", I don't mean to pay the same amount of attention to all features for the sake of completeness. Here, I'm a proponent of the 80/20 rule. Specifically, that the important 80% of the features be implemented first. That doesn't mean ignoring the remaining 20%, just that the rest of it will need to be hashed out later/eventually. An 80% product is enough for a demo/risk-loving early adopters, but ultimately customers want to pay for 90%-100% products.