Scaling a Lean Startup, The Story So Far.
blog.tommoor.com
blog.tommoor.com
It's the idea of being proactive and reactive - - and as a good developer you should master both and be able to switch between these states.
For example, backups and anticipations of future load should be proactive. If your load is close to maxing out today then don't wait till your web site is down before you begin optimizations. Know everything about your systems so you can take an educated guess of how many more users you can handle. Think about which strategies you can apply if you want to scale 10x, 100x, 1000x of your current load.
Reactive programming is great when you are exploring new territory and are unsure how many would use something. This is the state where you don't think about scaling to millions of users. This said, as a good developer always keep in mind how something can be scaled or how fast something is.
In other words: it's about finding balance between the proactive state and the reactive state. Don't optimize prematurely, but don't optimize when everything is burning down either. You have lots of data so use this to your advantage and make educated guess about your way of scaling.
Totally agree with what you are saying here, particularly once the idea is validated and you start to see good adoption. I've used todoist and wedoist for a long time and it certainly is reliable ;-)
This post mainly covers the really early stages before millions of users, where the most important thing is focusing on the product and market fit as much as possible. We certainly treated scaling issues in a reactive way at this point. I'd like to think we have got a lot better at being proactive as the service has grown and more people depend on us - for example the recent move to AWS was due to hardware constraints in our old setup, it was planned well in advance and executed with minimal downtime.
Couldn't have said it any better myself.