More concretely, your post is a suggestion to do something along the lines of "write a contract for a demo/alpha/MVP, then do a separate contract to improve things, iterate until done", right?
That would be ideal, but in my experience it needs to be phrased as a risk mitigation strategy, not as constraining one of three project management aspects.
Customers want business value. Some software systems that deliver that value cannot be broken into components or feature subsets that are sufficiently valuable in and of themselves. In these cases, the value of agile methods to the customer is that they can pull the plug at any time. That's the risk mitigation value that needs to be emphasized.
Absolutely agree that it's a risk mitigation strategy. Even if we can get to a 'do an MVP' and then iterate, I still see these types of contracts trying to fix more than 1 project aspect.
Customers want business value. Some software systems that deliver that value cannot be broken into components or feature subsets that are sufficiently valuable in and of themselves. In these cases, the value of agile methods to the customer is that they can pull the plug at any time. That's the risk mitigation value that needs to be emphasized.