Interesting. I wanted to suggest an exact opposite.
I'd love to have seen those products of yours. In the alternate universe I live in, almost all the SaaS products I see are toys, never progressing beyond MVP phase.
In my view of the world "toys" and "MVP" are orthogonal. Imagine an actual toy that is a choking hazard. There are lots on the market, and they even usually say, "choking hazard" on the packaging. The choking hazard is a potential liability that you might have been able to fix with more design work upfront and is hard to fix now that you've made a product.
MVP is a kind of overloaded term because it can mean that it lacks user features, but it can also mean that it contains technical debt that is a potential liability in the future, just like the choking hazard on a toy.
A "toy" application can have a minimum set of user functionality, but be "complete" in terms that it doesn't contain any of that future potential liability. There are some really nice "toy" applications and services that fill a really small niche and do it extremely well, without trying to tackle bigger problems. However, I wouldn't consider them to be MVP because they actually have a considerable amount of design beyond the minimum necessary to get it out the door.
Or tl;dr: "Toys" are uncomplicated, but not necessarily minimal. MVP is generally incomplete and not necessarily uncomplicated (because reducing complexity requires effort).
I have always considered this the great tragedy of APIs. Their promise is so great yet there are few ways of actually working with them outside of explicit vendor integrations that account for the idiosyncracies between most software. Noting that most SaaS is just differing UI interacting with object models, and it's a bummer that we build this way. It's like we are collectively building a rail network, but every single town uses a unique guage of rails.
Ecommerce software is about as close to okay at it as I have seen, but still vendor driven and still full of idiosyncracies. I can at least create a product in a PIM and it pipes through to all the places it needs to go once it is set up.
Agreed in general, but services like IFTTT and Zapier offer a very decent way of integrating otherwise unfriendly APIs, and I think that this will become even more straightforward and common with the rise of conversational interfaces like Alexa
Problem is, most services seem to be designed to interact in the absolute minimum. I use IFTTT myself, but just look at the integrations available! So little of them. 90% of times I have a flow idea, it can't be done with what's available.
(Come to think of it, I have a spare VPS, maybe it's time to try out Huginn.)
RE Alexa, call me a whiner, but "Alexa, ask $BrandApp to XYX" ruins the immersion a lot :(.
Ultimately, the problem is control. On-line services control both your data and how you work with it - from the flow of actions to UI[0]. An interoperable world requires vendors to give up a lot of that control.
--
[0] - They control the entire experience. As if they were a fucking Disneyland, not just a hammer, from users' point of view.
UNIX tools can focus on solving a single problem well because they interoperate between themselves, so you can join tools that solve different problems and make something useful out of it.
SaaS has no such option. It either does every little thing you need, or it doesn't solve the problem.
They're ultimately limited to which SaaS lets them, which is usually not much. For many, deep interoperability goes against the core objective of "engagement" (i.e. trapping the user in the service for as long as possible).
You have a single filesystem, so maybe you can open the same document in both one after another to work on the parts that need D and the parts that need C. Of course this relies on having a common format, but in the local-apps world we mostly have those, whereas in the SaaS world we don't even have a filesystem to share.
MVP is a kind of overloaded term because it can mean that it lacks user features, but it can also mean that it contains technical debt that is a potential liability in the future, just like the choking hazard on a toy.
A "toy" application can have a minimum set of user functionality, but be "complete" in terms that it doesn't contain any of that future potential liability. There are some really nice "toy" applications and services that fill a really small niche and do it extremely well, without trying to tackle bigger problems. However, I wouldn't consider them to be MVP because they actually have a considerable amount of design beyond the minimum necessary to get it out the door.
Or tl;dr: "Toys" are uncomplicated, but not necessarily minimal. MVP is generally incomplete and not necessarily uncomplicated (because reducing complexity requires effort).