> if you can get 90% more performance up front with only 10% more effort, go for it. Scale is only loosely related to performance. You can have an application

> if you can get 90% more performance up front with only 10% more effort, go for it. Scale is only loosely related to performance. You can have an application that performs pretty badly, but scales. This is much better than an application that performs well, but won't scale. Performance tends to degrade slowly, while scale is usually a hard limit (you've reached "n" users? server crashes). Hitting an issue of scale is usually a fairly traumatic thing for a service. I'd agree with the original comment that when you're starting you don't need fancy caching schemes, load balancers or replicated databases. Equally you don't want to build something that is incompatible with these in the future. It's a terrible pain and is probably indicative of a bad design... As the other reply said quite well: A good, simple design will allow you to move faster and scale better.. I'm a big fan of "optimise last", but I think this is often interpreted as "put together badly and fix later"... It should really be "quantify what you optimise".