I don't think it's nearly that cut-and-dry. The most elegant code in the world is pointless if it doesn't solve a real problem (the end product), and the an unm

I don't think it's nearly that cut-and-dry. The most elegant code in the world is pointless if it doesn't solve a real problem (the end product), and the an unmaintainable and unscalable mess of crap that actually shipped on time is equally pointless if it's so broken that user's can't use the product or developers can't improve upon it. 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.