In my org, I have created a process to clearly define what makes a prototype different from a MVP. It appears to be somewhat successful for what my goals were, which was to prevent prototypes from turning into long-term production code.

Prototypes have no restrictions that we would normally place on code (coverage %, automated pipelines, etc) and can only be created in a sandbox AWS account that has no access to our internal systems. It allows developers to prove out concepts or work with product to quickly iterate on PoC.

On the other side, PoC's have a limited lifespan and if successful, are expected to be re-implemented as an MVP, following our internal standards and guidelines.

This is excellent. I'm always a bit wary of treating something as a "prototype", because of the number of times I've seen things evolve into the actual product.

I like the separation of AWS accounts.

Yes it does. The clue is in the name - prototyping. A prototype is only supposed to prove the concept works; it doesn't need to be good.

The problem is that most companies can't do prototyping because they don't have the resources. They build a prototype, and then they don't throw it away and build the proper version and they use as production.

I was hoping to see the word 'protoduction' in your comment.

This is such a good word, great find!

There are so many things in production that are prototypes (even when people/companies cannot allow themselves to recognize them as such...), having a word for this pattern is great.

Yes. There's a reason why best practices are called "best".