I like the old mantra "Fast, good, and cheap. Pick two." If you build one big project all at once, it may not do anything you want until it does everything you want. Whereas if you start small and keep your features separate and cooperative you are more likely to get some of what you want right away, and over time get everything you want working together.
The danger here is that in optimizing for fast and cheap you may be prematurely optimizing yourself away from being able to do "good" without a complete re-write. Fast and cheap has a seductive nature of getting good feedback on broad concepts, but it also tends to lead to very shallow implementation of these concepts. Like a lot of evolutionary algorithms, it is easy to get caught in a local maxima and not realize that you have only reached the top of a foothill while a competitor that can see where the mountain really is will have made less progress but will end up miles ahead if you discover that you climbed the wrong slope...
I agree that whatever you optimize for early, you are probably stuck with later.
There are more than three vectors. "Good" could mean reliable, secure, highly functional, or many other things. Picking any three vectors and analyzing the tradeoffs helps to figure out how to apply resources.
