Corollary

Oh, and one simple thing my ruminations lead to is: the prototype must be written by the same people who will write the actual application, or else there's no point in it: the actual developers won't learn anything from it.

Solution by coincidence

Pragmatics have coined a term "programming by coincidence". Generally it describes a way of coding when a developer tries something without inner understanding of why it works, it works, it's considered to be the final solution, the scheme repeats.

It's interesting to look a bit ahead at the moment when the product has grown substantially and is used by the customer: what does the customer have at this moment? And I'm not only speaking about the situation when coding was precisely "coincidental" — it may have been a series of steps slightly compromising design for features with full awareness. It may have been ignoring 10% of requests that  will eventually lead to substantial changes in the product. It may have been failure to refactor and redesign along with new requests. It may have been lack of communication with the customer, or customer's drastically altered plans or improper architecture or platform choice.

So, what is it that the customer has in hands? From the purists standpoint, it's probably but a big ball of mud: hard to understand, hard to change, next to impossible to evolve.

On the other hand, it does the work for the customer. It eases his life (or life of his clients) and automates things. Re-doing it incurs additional costs, and some claim that it should by no means be rewritten from scratch, if that is your first intention:

"The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. [...]
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years."

Then, each of the requests successfully addressed is "documented" in the code, by the code (of course there are no tests in our muddy product!). The product can even show this specification of things to the person operating it.

So it's definitely worth something, but at the same time there's something pathetic about it... I think the situation should be cleanly stated by the development team to the management so that they planned for some "curing" phase. And the management — they should probably have some objective metrics that will show them — unless they can "feel" it — that this kind of situation has arisen.