In principle I agree with what he is saying: If you know what you are going to need you should put in effort up front so you can react faster later. The problem

In principle I agree with what he is saying: If you know what you are going to need you should put in effort up front so you can react faster later. The problem is with knowing what you are going to need. You hear that startups end up moving away from there initial ideas so often that bar for being sure that you "know" what you're going to need is very high. I also think he overstates the difficulties of abstracting out extensible pieces as you go. His point about your # of customers being proportional to the difficulty of refactoring is well taken, but for an early startup this probably does not mean as much as he suggests. On the web you can do a great deal that is transparent to your customers. The risk of this approach might lie more in not having to discipline to take the time to refactor as you go as opposed to not having the technical ability. 37 Signals seems to have had certain project go very well for them by pushing down abstractions as they went (granting however, that everyone can't count on a gang of open source hackers coming in and both contributing to and evangelizing your product's infrastructure - though maybe this isn't a bad goal?).