Stop thinking about how to scale. Startups die from not having customers.

I once worked for a start-up that had a grand vision of lightweight real-time messaging. This was 1996, and we were going to broadcast in real time, to zillions of clients, the events of the Summer Olympics. We had "push" stuff that worked really well, we had permission from IBM to do periodic scrapes of their event database, and we came up with a scaling system for handling feeds to massive numbers of clients. This was going to be a fantastic demo for potential customers. The publicity was going to be great.<p>We got everything ready, rented some co-lo space, got a bunch of servers set up (I think each miserable little Pentium 90 server could handle tens of thousands of clients), and . . . our top was maybe a couple dozen concurrent users. We could have run the thing out of our offices on our worst sales person's crummiest laptop. While that sales guy played Quake.<p>[Later, our /best/ sales guy had a patter that went like: "Well, we did this real-time monitoring app for the Olympics, and it scaled to ten, twenty thousand clients on a machine. You know how many we got? THIRTY."<p>Start-up was eventually bought, and then transitively bought, and I wound up with some shares of Oracle (spit).]

The best advice I've ever heard regarding scaling is to only worry about one level of magnitude. If you have 20 users, make sure you can scale to 200 - any farther than that and you're likely wasting your time.

The way I think about scale is:<p>1) Know your bottlenecks and write them down. This is where you will look first if you have problems.<p>2) Know how you will throw hardware at it or change configurations if you find yourself with sudden growth you didn't expect. You need to create a buffer so you have the time to solve real code issues. Write it down.<p>3) Whenever you make an architectural choice, make sure there isn't one that's equivalent in engineer time that will be easier to extend later.<p>Otherwise, just do whatever helps you learn about the product the quickest.

I think there is an exception to this idea for startups that require data-centric scaling. If you are planning to grab as much data as you can and as quickly as possible, this could require scaling even when the user count itself is small. I had a startup that ground to a halt because I hadn't anticipated the sheer amount of data that the app would collect even before I had more than a handful of users. Of course, that isn't the traditional kind of scaling that people talk about.

This is generally true.<p>However, just for fun, I'll note here that we are/were an extreme case where we spent a lot of time thinking about scaling in the early months and it paid off when we finally got traction (100 visits per day to 2,000,000 visits per day in 30 days). Sometimes it does matter. Moral: don't follow advice blindly.

I've never understood the obsession with scale when there are so many challenging problems left in user interface technology are relatively ignored. The room for innovation is staggering, yet we obsess over nosql.

Certainly the most disappointing startup experience I ever had was with an early Internet firm that had spent too much of '95-6 building their hardware and most especially software (custom C++ database) to insanely scale, taking so long their angel timed out due to a sudden need to pump money into another venture.<p>When I joined they were closing with new investors who turned out to be devils only interested in owning 100% of nothing, they essentially ran it as a vanity company after chasing off almost all the competent staff, KPCB who got <i>very</i> interested in what we were doing and who could have made a fantastic difference due to their relationship with Netscape etc.<p>That plus the company didn't do any Customer Development, ran in total stealth mode and spin in circles a whole lot theorizing about how people might use our service; as Blank says, there are no facts in the office, only opinions.<p>And we bet too much on our initial debut splash, which turned out to be a dull thud due to the incompetence of our marketing guy and/or the tech media (every article focused on the least attractive way out of 3 to use our service which was downloading a plug-in for your browser).

You could even write that more starkly: worry about supporting your customers because customer support is the only thing that you can't scale easily, everything else will eventually work out. Are there lists of start-ups that failed because of scaling issues? Are there comparable lists of start-ups that failed because of marketing, sales, product, vision, support and a 100 other pitfalls that a start-up can easily fall in to?<p>I could not name a single company that folded because they could not handle the luxury problem of scaling. Because really, when scaling is your problem, you have no problem, you've figured out a way to beat the odds on all that other stuff so scaling will be solved as well, one way or another.

Because lots of startup die for not having customers enough (or at all!), but I haven’t heard of any died because at first was not able to scale millions of users.<p>...So you never heard of Friendster, then?

I have to say a big AMEN here.<p>There are many startups that should just buy a dual-quad core Nehalem (or AMD Magny-Cours) system with redundant power supplies, 32GB or more of RAM, and fast disks (or even spend on a RAID5 of SSDs) and stop worrying about scaling for the meantime.

I worked at a startup where the relentless focus on being able to scale to support millions of users from day one hurt the business very severely and was one of two reasons that the company failed. Spending almost 50% of the venture funding raised on hardware that was never used when 10 servers would've sufficed was not a smart idea.

Lately it seems that every article I read about web technology is about scaling techniques. This stuff is fun to hack on but I have to agree that it's very unlikely that it should be the focus of any small company. I spoke recently with an engineer from a small but profitable and highly visible specialized e-commerce site. He runs their site quite comfortably and inexpensively on <i>two</i> machines.

I wish I knew how to learn how to get customers as well as I know how to learn how to scale technology

This is not really a startling revelation, businesses need revenue to succeed but where does revenue come from? Customers .. duh! They also need to attract customers to gain angel inventors, funding, and partnership deals.<p>I'm not sure that I agree with the author's opinion that time would be better spent innovating on User Interface / usability. Having run a business since 2000, I would say that delivering an innovative service to a very specific marketplace and at the same time developing a rapport with that segment should be the ultimate goal of any startup.

Its amusing that none of these comments even touch on the articles premise, which is that you need to be solving problems that someone (i.e. customers) else believes is important.

I think it'd be an oversight to not stay on top of the new technologies that scale better.<p>A document store fits a lot of problems much better than doing everything in Postgres, and offers easier maintenance and replication. And can offer a lot simpler architecture when all is said and done.<p>But yes, obsessing about scaling on an app that has no users can be a very big time sink. Much better to just hack out some software with whatever tools are the most productive, and get a few customers to drive the human side of business requirements.