If you like Song Exploder, a friend of mine and I started a music production podcast where we dissect one song each week that you might also like: http://songaweek.net/
I sit next to the team that built this, and work with them nearly every day. They are every bit as awesome as the dropdown would suggest, and you should definitely email Chad about working with them if you are interested in projects like this.
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.
I worked with a guy a couple years ago who used the planets and nearby stars as a version numbering scheme. For example, the first revision of a file might be "Jupiter" and the second revision might have been called "Mars." (Of course, he didn't use the planets in their natural order)
He also refused to use real version control or even any kind of on network backup and insisted on using a Zip drive to back up all of the code he was working on. Needless to say, we had an intervention that involved hiding the Zip drive, and he quit in disgust shortly after.