Prototypes are fine as proofs of concept, but not as what you sell to a customer.
There must still be a flexible top-down architecture, that is re-factored as required. This is because the most times a product changes is leading up to the first and second released versions. Without a flexible architecture, every iteration will involve too much rework on too many parts of the product.
This is especially important if you do customisations for different clients. I have seen where poor class design has resulted in too many having to be changed for each client. This was for a product where they basically sold the prototype and didn't then get enough time to make it production-ready.
Use prototypes just for testing out the feasibility of a design aspect. When you really want good info to be able to accurately plan moving forward, take a representative module and design it properly from top to bottom. You will also flush out many issues that may affect the overall design, thus saving a lot of rework that would have occurred across the whole product otherwise.
Architecting may take extra time, but it does involve just a few core people, rather than having lots of developers wasting time and money to do unnecessary rework, or worse, lots of wasted support time and disgruntled customers.
I am not writing here about full-blown TOGAF (which gets real information-dense just drilling down one level), but having a practical approach to design and development.