You nailed the opposite of an MVP, which is to deliver it immediately and improve it later.

Theres a lot of reasons why it makes sense to sell something before building it. You want to be up front about this fact but getting commitments to buy something is a good idea before actually spending money and time to build it.

Of course. That has nothing to do with agile MVPs, though.

Well you've either got to make it clear that it doesn't exist yet, or not actually charge them until you build it. Otherwise that sounds like fraud.

There's some validity to the criticism, but that's more the intersection of short-cycle methods and American "hustle" culture than anything to do with an MVP approach itself. People with more integrity can take an MVP-centered approach and just be honest with customers about where they are.

Indeed, I think that honesty works better; underpromising and overdelivering is a great way to build trust among your initial customer base. Trust that you need to carry people through the inevitable bumps and anticipations of an early-adopter experience.

What in particular did you not like about their API?