Home

What was it like to transition the infrastructure at an early startup as you started to scale?

Scribd actually had a lot of scaling challenges because we worked in a consumer facing site where we had, unfortunately, a low ratio of revenue to users. We had eighty-five million users a month, and we weren't making very much revenue at all.  We also grew Scribd at a time when there were much less information and tools available to scale websites than there are now. When we started Scribd, Amazon hadn't even invented EC2 yet, to give you a sense of how long it's been. So, scaling websites was a lot harder then. There wasn't NewRelic, Elastic Beanstock, and it's much easier to scale websites now. When we were running Scribd, there was a period of several years when we were the largest Rails site on the internet. This is before Twitter eclipsed us as the much, much larger rail site on the internet. But for a while we were really on the forefront of how to scale a Rail's application. It sounds fancy, but actually what it means is that, instead of working on our product we were spending a lot of time figuring out how to make rails scale.  Here's the thing about scalability, at least this is my personal thing, engineers love to talk about scalability because it is a really fun problem to think about, and a really fun problem to work on. But, as a startup, your job is not to work on fun and interesting computer science problems, your job is to actually build a business that makes money. And every hour that you're spending figuring out how to scale your infrastructure and keep your website from falling over, is an hour that you're not spending improving your product and getting more users. So, the most common mistake that I used to see in founders back in the early days of Y Combinator, was premature optimization on the scaling side, where in preparation of this launch that they thought was going to bring them a bajillion users, they would work really hard to build a super scalable infrastructure that could handle a million simultaneous users, and of course most at the time, the million simultaneous users never actually come. So, all that time just goes down the tubes.  The approach that we always took with Scribd was, scale as needed, which is ‘do as little work as possible un-scaling’. www.scribd.com

4594 views
1 comments
1 upvotes
Related Tags
Anonymous Author
Scribd actually had a lot of scaling challenges because we worked in a consumer facing site where we had, unfortunately, a low ratio of revenue to users. We had eighty-five million users a month, and we weren't making very much revenue at all.  We also grew Scribd at a time when there were much less information and tools available to scale websites than there are now. When we started Scribd, Amazon hadn't even invented EC2 yet, to give you a sense of how long it's been. So, scaling websites was a lot harder then. There wasn't NewRelic, Elastic Beanstock, and it's much easier to scale websites now. When we were running Scribd, there was a period of several years when we were the largest Rails site on the internet. This is before Twitter eclipsed us as the much, much larger rail site on the internet. But for a while we were really on the forefront of how to scale a Rail's application. It sounds fancy, but actually what it means is that, instead of working on our product we were spending a lot of time figuring out how to make rails scale.  Here's the thing about scalability, at least this is my personal thing, engineers love to talk about scalability because it is a really fun problem to think about, and a really fun problem to work on. But, as a startup, your job is not to work on fun and interesting computer science problems, your job is to actually build a business that makes money. And every hour that you're spending figuring out how to scale your infrastructure and keep your website from falling over, is an hour that you're not spending improving your product and getting more users. So, the most common mistake that I used to see in founders back in the early days of Y Combinator, was premature optimization on the scaling side, where in preparation of this launch that they thought was going to bring them a bajillion users, they would work really hard to build a super scalable infrastructure that could handle a million simultaneous users, and of course most at the time, the million simultaneous users never actually come. So, all that time just goes down the tubes.  The approach that we always took with Scribd was, scale as needed, which is ‘do as little work as possible un-scaling’. www.scribd.com
3 upvotes