Low-fidelity prototypes are never intended to be kept and integrated into the final product. But when building a software-based system, developers can choose to do one of two things: either build a prototype with the intention of throwing it away after it has fulfilled its immediate purpose, or build a prototype with the intention of enolving it into the final product.
Above, we talked about the compromises made when producing a prototype, and we commented that the "invisible" compromises, concerned with the structure of the underlying software must not be ignored. However, when a project team is under pressure to produce the final product and a complex prototype exists that fullfills many of the requirements, or maybe a set of vertical prototypes esxists that together fullfill the requirements, it can become very tempting to pull them together and issue the result as the final product. After all, many hours of development have probably gone into developing the prototypes , and evaluation with the client have gone well, so isn't it a waste to throw it all away? Basing the final product on prototypes this way will simply store up testing and maintenance problems for later on; in short, this is likely to compromise the quality of the product.
Evolving the final prototype into the final product through a defined process of evolutionary prototyping can lead to a robust final product, but this must be clearly planned and designed for from the beginning. Building directly on prototypes that have been used to answer specific questions through the development process will not yield a robust product. As Constantine and Lockwood (1999) observe, "Software is the only engineering field that throws together prototypes and then attempts to sell them as delivered goods."
On the other hand, if your device is an innovation, then being first to market with a "good enough" product may be more important for securing your market position than having a very high-quality product that reaches the market two months after your competitors'.
Excerpt taken from Preece, Rogers and Sharp, Interaction Design, beyond Human Computer Interaction, Wiley, 2002, p. 249.
Reference: Constantine and Lockwood, Software for Reuse Addison-Wesley, 1999.