I think some programmers focus on the code, while others focus on the end product. It is a philosophical difference. The first make great employees. The latter make great start-up founders.
Great people need to find a balance, and I don't think leaning towards one side or another shows whether someone would be a great employee and/or founder. This "ship early/ship often" and "move fast and break stuff" attitude is ok for immature products, but there's still a minimum level of quality you need to reach, and as your userbase grows and your product matures, it's almost certainly going to be important to raise the bar on quality.
Shipping prototypes is fine, but you have to keep in mind that if it catches on, your plan to rebuild a non-crap version (invariably you had this plan) will fall through because something else came up.
My rule of thumb for prototypes is to get the data models close to right, and untangle the rest later. Pulling apart spaghetti code isn't too bad as long as there's reasonably sane intent behind it. I can fix systems where people are updating state from the views and writing to the db in all sorts of unimaginable, horrible ways; however, if you're not storing the right info, you're pretty screwed and have a hell of a migration process in your future.