Claramente, a prototipagem de aplicações usa um conjunto diferente de tecnologias do que o desenvolvimento de qualidade de produção. Mesmo que eles se sobreponham - e de fato o mesmo framework pode ser usado para ambos - é muitas vezes preferível escrever código rápido e sujo de uma forma, e código de produção "permanente" em outra. De fato, quando se itera rapidamente, faz sentido escrever um componente com a expectativa de que ele será jogado fora. Escreva-o a fim de reescrevê-lo do zero mais tarde - e que ainda é mais rápido e mais alta qualidade do que escrevê-lo "bem" da primeira vez.

Caso em questão: desenvolvimento orientado para testes (TDD) pode ser desnecessário e prejudicial durante o desenvolvimento rápido. Há também o lado inverso do argumento: se você ficar preso... escreva alguns testes. Ou se o código tornou-se completamente incontrolável, desdobrá-lo escrevendo testes. A mentalidade do testador é uma boa, e ajuda a obter um un-stuck, e definitivamente ajuda a escrever código mantendível a longo prazo. No entanto, se você sabe que o código pode ser jogado para fora ou reescrito, ou até mesmo reescrito mais de uma vez - do que test-driven pode ser ineficaz e deve ser abandonado.