When I create software prototypes, one of the big power-ups is the fact that I don’t need to address the general case. All I need to do at first is to show that what I am doing works for *some* cases.
Most people who understand what is going on will be able to see how things generalize. Meanwhile, I am avoiding doing a lot of unnecessary work.
This is important because a prototype is essentially an assertion that “it would be interesting to do something like this.” It’s not really a product, and it doesn’t really yet have user.
In fact, it’s kind of a way of fishing for potential users. In that sense, a prototype is essentially an advertisement.
If the prototype needed to be fully functional, and work for all cases, it might take ten times as long to implement. And at the end of that time, people might still say “nope, don’t need it.”
So it’s very important when creating a prototype to choose the right narrow set of cases that prove your point. Anything more, given the purpose of your prototype, would actually be counterproductive, and frankly a waste of time.