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?).

Good post! I think having a grand design ahead of time is good, if it’s a good design. To me, this is about the scientific approach vs the engineering approach. You can get in trouble with either one. Option one: you have your grand design but nobody needs it. Option two: you keep iterating something but at some point improvement stops (try to cure cancer this way).