Prototypes & Edge Cases
There are two types of prototype. One you throw away and one you can build on.
If you’re making the first one (which should only be to evaluate the user experience) you should explicitly not worry about edge cases. Get straight to something clickable and park the form validation.
However, if you’re using the prototype to evaluate the technical implementation, it’s dangerous to code something without considering edge cases.
There are edge cases like edit metadata and delete and re-sort listings. These are actually feature requests and shouldn’t get in the way of a prototype. You can augment your code when you go from prototype to product.
Then there are edge cases like race conditions, uniqueness constraints, that if you’re making a prototype to evaluate the technical implementation, you can’t ignore. How can you really know if you’ve modeled it, if you haven’t modeled it properly?
The advantage of prototyping bug free is that you can then build on your code, instead of throwing it away. So, if you’re following a rework “half a product, not a half assed product” approach, your prototype becomes a product: minimal functionality but rock solid in what it does.
