Perhaps the old adage of 'build one to throw away' helps here? Assume the experimenting / PoCs and bodges required to get that MVP in front of customers will be disposable: once you have established the value, you have bought some time to do it better, and you understand the UX better as well.
Then there is the Minimum Viable Product (MVP) concept itself, create only enough to show someone, get feedback and iterate. This minimises the code that needs writing, so it's less painful to dispose or refactor heavily.
As Scott notes here - you can defer the quality attributes for a while, as long as you know how to find them again (tagged as tech debt). You also have to consider all the stakeholders, UX applies to operations just as much as customers - especially when you are ops!
I think you may be confusing an MVP with a prototype, at least the way I understand MVP, which is the product that satisfies the core need of the consumer. Then, once it proves it has a market, it can be expanded with additional features to make it more attractive. Although this supports the notion of easy disposal and rewrites, you may still have an MVP that has a pretty hefty codebase, which will not be trivial to refactor.
Possibly, I treat MVP as a moving target, prototypes are one-offs. Isn't language great :)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.