

Cripple the Prototype: Sabotaging your best ideas - cscotta
http://boundary.com/blog/2013/02/27/cripple-the-prototype/

======
jordw
Having done this sort of thing both ways, it's clear to me that there is much
value in getting the consensus and energy of teammates and potential clients
behind your project before it gets too far along.

When designing a prototype service / API, it's really easy to miss important
use cases and failure modes that may be obvious to a fresh set of eyes, and
get lost in the fun of creating it. Once this code goes to production, it's
always harder to go back and fix these deficiencies, especially if a large
number of clients come to depend on the API in its prototype form.

It's better to scrap and rewrite the prototype with multiple people involved,
as it will save time, pain, and churn in the long run.

