Web 2.0 Companies DO NOT need To Scale
Posted by Ian Holsman
In Jeremy’s Article: Web 2.0 Companies NEED To Scale, he highlights a certain process that he belives most start ups follow.
Yeah. Here’s their process:
- 1. Start with a handful of users. This is too much for ded box.
- 2. Move to dedicated server.
- 3. Add a few more users til they’re at 100. This is too much for one box.
- 4. Add more hardware. It’s obvious this isn’t enough.
- 5. Recode.
Here is my view (albeit never working in a startup, but having working on integrating a couple of small-large ones) of how it works.
- 0. get your savings together
- 1. build a prototype, show it to some friends and put your hand out for some $$$
- 2. with something functional, approach the VC’s
- 3. use VC cash to just buy more machines, and concentrate on adding features to bring in the money, not ‘optimized’ solutions
- 4. concentrate on your growth rate. you need to have this as high as possible, not your user base
- 5. once you have become a ‘market leader’ and have series ‘B’ funding, then concentrate on employing a person to tune your application, or just buy some new machines which are 2-3 times faster than the ones you originally have OR
- 5. Flip it
- 6. Let the buyer integrate the application into their infrastructure, processes and standards. From my experience this will double the user-base and increase the growth rate as they put your application on their scalable services, and optimize the unscalable bits by replacing them with their exsiting stuff, or rewriting them. Maybe it’s just me, but the value of the aquisition isn’t the technology, it’s the userbase.
- 7. Wait a year till your options vest and repeat/buy a yacht
If I was starting my own company, I would be concentrating on increasing the value of it ASAP, and I would do it in two ways. Increasing the features and user base as fast as possible, making it as hard as possible for anyone else to enter in just after me.
as long as the user experience is acceptable, I would not be concerned about scalability in the slightest, especially if spending $5k to buy another box will make the problem go away for 3-6 months/until I can get some more funding.
This article can be summarised as “I would rather have a developer working on something which will increase the money coming in today, rather than having him work on something which will increase the money coming in a month from now, as I don’t know WTF will be happening in a month”
Wanna buy a company? ;-)
smp
Sorry, I can’t help but giggle when your entire business plan relies not only on VC funding but also becoming the market leader AND flipping.
If you dont’ think you need scale to do that, perhaps we’re talking about different definitions of scaling.
Hi Jeremy the plan is becoming market leader ‘OR’ Flipping, not both ;-) (I’ve only worked for one company who’s plan was to be the 3rd largest in the field)
and the point I was trying to make is that you shouldn’t worry about scaling until you need to, and for some cases that is never.
The reasoning behind not worrying about scaling is that in a lot of cases people worry about the wrong things. They will spend hours getting that code tuned just so, and have it running in 10ms less time, only not to realize that the code is only run once a day.
the other reason is some features don’t work out, for example writing the mousetrap your marketing person thinks will have people beating down the path to your door. now isn’t better to get that mousetrap up first, and see if he is right (in a day) as opposed to writing it with scalability in mind, waiting a month only to find that it isn’t used? even if he is right, you will have been validated in the day, and can then proceed to write a scalable solution while people are using the feature on the site!
you should wait until the problem occurs, and then address scalability. i’m not saying ignore scalability, just to address it when it is about to become an issue, and concentrating on growth and income generation. I’m not saying not to worry about it, just not to implement it until it is needed.
I’d argue that you should only worry about scaling to the degree that your business depends on availability.
If you can go two years and grow to hundreds of thousands of users with needing to worry about “real” scaling, then don’t. Just constantly build out, toss a load balancer in and be done.
But, if your business absolutely needs to be up to survive (which was the point of my post), then you need to build your software with that in mind.
I’m not saying you need to put 250K in hardware in on Day 1. I’m simply saying that your app and your infrastructure needs to be ready for it, otherwise you’ll lose time and money retrofitting.
The cost between being “scale ready” and non “scale ready” is just about the same. This is why it blows my mind when the companies I’m dealing with not only aren’t ready, but they SAY they are - without realizing how much they aren’t.
ps: Overall I agree with anyone who says users, features and growth need to be the largest priority, not infrastructure. Without users, features and growth you have no company.
I just dont’ want companies thinking they are scalable or spending months retooling their apps just because they werent’ thinking about things up front is all :)