Early-Stage Startup: "We've designed the system to handle millions of users and be fault-tolerant so that there is no single point of failure and can assure our users of 99.999% uptime. We're prepared!"
Me: That's premature scalaculation. You're worrying about scalability too early. Don't blow your limited resources on preparing for success. Instead, spend them on increasing the chances that you'll actually succeed.
Apologies for the metaphor, but I wanted to use the word "premature" and decided to leverage the most widely recognized phrase with that word in it.
In startups, the technical founder often wears his skills as an architect of scalable systems as a badge of honor. Lots of time and money is spent making sure that should the company ever hit the spectacular success that everyone on the team knows is inevitable, the system (software and infrastructure) will be able to handle it. Quite often, this is misguided.
In the early stages of a startup, whether you're venture-backed or not, the primary constraint you are dealing with is limited resources (time and/or money). These resources should be spent trying to figure out what is going to work and not on intricate software designs, code optimization and infrastructure upgrades. Should the company indeed succeed beyond your wildest dreams, that's a high quality problem and more resources will likely become available as a result.
One of the reasons why startup founders so often spend too much too soon on scalability is that it is satisfying to do so. You can spend resources and have something to show for it. It is also easier to take credit for tangible progress. "Hey, we just tested the system last night with a million users and it didn't crash!". Or, "We just upgraded our hosting infrastructure so we can guarantee our users 99.999% uptime!" It's also useful to tell potential investors. However, it is much harder (but usually much more meaningful) to spend resources on things that are not quite so black and white: like learning about your market, putting a few more iterations of the software out there, finding more users/customers. All of these kinds of activities are much more frustrating because they're so much harder to control.
While writing this, I came across an older article (Dec 2005) on the topic of scaling from the 37signals blog: Don't Scale: 99.999% uptime is for Wal-Mart . David does a great job looking at the practical side of the issue. Given that he's part of a team that went on to support hundreds of thousands of users (and lots of paying customers), I think his perspective is highly relevant. David went so far as to leave the first comment to his own article as a pre-emptive strike against the inevitable backlash:
"The preemptive strike: Not worrying too much about scaling doesn’t mean building Basecamp on an Access database with a spaghetti soup of PHP making 250 database calls per request. It simply means having a profitable price per request, chilling the f*ck out, and dealing with problems as they arise."
As a tech-founder myself (and a career software guy), I have to reiterate David's comment above. I'm not suggesting that you create a crappy system and ignore fundamentally good practices. Just don't go overboard on the optimization too early in the game.
Once again, my advice: Don't fall into the trap of spending your limited resources on planning and preparing for success. Instead, spend them on things that will actually increase your chances of success.