Here are my 5 laws of prototypes that I've found to be universally true:
1) The answer to any prototype / feasibility question is always yes.
Okay I stole this one from Facts and Fallacies of Software Engineering - Robert Glass. In my experience this is always correct.
The problem is really one of what question is being answered. Prototypes tend to answer 'can we do this' and the answer is always yes.
However, the real question that should be addressed is something more like 'given the cost to do this, should we do it?'
The difference might be subtle, but if you apply it you are going to save a lot of money.
2) Whatever poor coding practices you use to build your prototype will be replicated in the final production version.
Developers tend to be lazy. It is easier to solve a problem by looking at how someone else did it and tweaking it if necessary than it is to start from scratch.
3) No matter how poor the performance of the prototype the production version will be much worse.
See #2. Bad coding practices almost always result in poor performance and lots of bad coding practices results in really bad performance.
4) Once in production a prototype will never die.
There is a perfect example here. This prototype was suppose to be pulled down in January 2003.
It's still going strong. It is very hard to justify taking away functionality from customers even if it is only a few and the functionality is limited, so it just doesn't happen.
5) Any controls used to build the prototype will be used in the production version even if they aren't appropriate.
See #2. Lesson here is when you build a prototype don't use the easiest control just to get it done.
You are going to have to live with that control for a long time so choose the control carefully.
Got any more good ones to add to the list?