The future-proof startup
All of the production clusters I've retired have been ready to scale. As I pulled their plugs and listened to their disks spin down, as I slid them from their racks and thanked them for their service, each and every one of them was programmed to handle floods of users who never came.
When I terminated the production instances of my crisis management as a service company, those servers could dynamically scale to 1M active users per day.
I've written load balancers where there was no load. I've prepped hot failovers when there was no user to notice a cold failover. I've backed up offsite when the only user data was my team's. It was time which should have been spent growing the core product and user acquisition tools.
Before the A round, the only scaling preparation a web startup needs to worry about is picking materials that have been proven to scale. Before that time the team is too small, the workload too varied, and the user base too dinky to spend more than a day or two on scaling problems.
I can do a lot in a day or two: AWS now provides server instances powerful enough to get startups through the first year of business. Deployment tools like Chef come with massive libraries of administration scripts which, when combined with one of the many monitoring systems, give us the ability to quickly change configurations should we get a mention on Good Morning America. The days when we had to provision using a two year timeline are gone.
After the A round closes there is a moment when everyone realizes that something needs to be rewritten in order to scale for the next growth spurt. If you've been around the block a few times then it won't be something huge. But it often is and it feels bad. You think that you should have seen it coming so it feels bad.
Do you know what feels worse? Retiring your production machines and shutting down the business because you spent most of your dev time on scaling.