> Sometimes you have to optimize for your development time first and product > development goals, and leave the optimization till you get a bit of runway. Tha

> Sometimes you have to optimize for your development time first and product > development goals, and leave the optimization till you get a bit of runway. That's a typical way to postpone and fall into a trap. Not all optimizations take huge amounts of time. And certainly there are some architectural decisions you can take early on that can save you a lot of wasted time later. The most common is to prevent bottlenecks. For example, it's not necessary to make a clustered DB from launch day but coding and managing the UI and middle-ware to be ready for a switch to clustered DB usually takes very little impact. If you don't do this and the site becomes successful, re-engineering your whole site to support a new DB is usually close to impossible or extremely expensive. The site ends up in the DB hardware feedback trap just like in the article. Edit: format fix.