For the record, I don't think it's a problem if someone's prototype is buggy. That's inherent to the nature of prototypes and setting the quality-expectation too high would prevent independent or amateur developers from implementing and sharing their ideas.

What I do think, is that:
1) there is a significant difference between a prototype and a product, 
2) I should expect a product to meet industry standard practice,
3) it should clearly communicated what is a prototype and what is a product,
4) and it's generally a bad idea to further-develop a prototype into a product, without going back to the design board one more time.

I will continue to share interesting prototypes, as I find them, as I like seeing how people react to the basic idea.
But you will know, when I think something is a product worth relying on.

This is where I am. 

 💜🦾 

 A true product must solve real problems not made up and exaggerated problems 

 A product is designed to solve an end user's problem, so it should be fit for an end user to use.
This is development.

A prototype can be useful in figuring out how to solve a developer's problem, so it merely has to work well enough to prove some concept.
This is research.

I am saying that there is a difference between R&D.  

 There is value in solving made-up problems, in order to have a use case for implementing a concept. It doesn't have to ever be put to use, to have value.