There's one thing I can guarantee any new startup is going to be worrying about when they launch: "Is my one (or less) web server enough?"

I've heard the question quite a few times. When we were in that stage, it was one of my biggest worries (so much so, that we initially launched a private beta). Seeing as it's a common worry, this post will address two related issues: how scalable is one web server? and should you launch a private beta?

How scalable is one web server?

More scalable than you think. I'm going to qualify that by saying that if you don't program with scalability in mind or are an idiot programmer, this might not apply.

Although we were lucky to have an awesome clustered infrastructure set up from the beginning (that I had spent a year developing for a separate venture), we actually ran Weebly off of one web server for a very long time. In fact, we can still run Weebly off of one server, total, if needs be. We currently have over 300,000 users, over 10 million page views a month, and are ranked about the top 6,000th site worldwide on the internet, and can still run off of one web server.

Plan for scalability, of course. Program with scalability in mind. But intelligently used, for most web apps, one web server can last you a long time.

Should I launch a private beta?

Short answer: no, launch public. Longer answer: probably not, launch public.

Everybody (including, initially, myself) thinks about launching a private beta when launching their product. But after seeing quite a few companies and advising another few, I think it's a bad idea.

Why? I understand the reasons for: You're scared that your product isn't ready -- or, you're positive that your product will be too popular. Opening in private beta will create an air of exclusivity. And you don't think you can scale. Et cetera...

1) Your product may or may not be ready, but it won't be that popular.
2) Your private beta won't be exclusive. In fact, nobody will know about it.
3) You can probably scale with a little effort, if things do actually go really well.
4) If you don't open up completely, you are losing users.

Think about things from your users point of view. You literally have about thirty seconds of their attention (if you're lucky). They want to like your product (they read about it, and it sounds cool). BUT, they can't try it out. It's not that they want to forget about it, but they have so many other things grabbing at their attention. Even if you ask them to submit their email address (most of them won't), you'll still convert less than 50% of those to users when you email them. It's not that they're idiots or trying to ignore you, it's just that you don't have their attention any more. The worst thing possible is if somebody wants to try your product, but can't immediately, while you still have their attention.

Basically, you're losing users. You can't afford to do that.

Even worse: if TechCrunch or any other large press source posts about you during this time, you've lost all their readers that might sign-up. And very likely, you might not get that coverage again.

There's only one reason I've ever advised anybody to try a private beta: if you (and other people around you) think that you aren't ready yet, and you need a small (read: 50 or less) group of people to try things out for you.

Occasionally, it seems to work out for some people, but I think this is more the exception than the rule -- and their product probably wasn't ready yet.

What can I do about it?

Ok, so you don't want to be like that new Yahoo! life casting thing that was down the entire couple days after it launched (even a worse way to lose your audience than a private beta, but not by much).

What can you do? Set the bar for a minimum level of service, and give that to as many people as possible, automatically. If you think your system can handle 2,000 signups, create a limit at 2,000 signups, and display a nice friendly error message after that. Make sure you'll be notified, and then put the rest on a waiting list. But don't set the limit too low. And make sure that if you hit the limit, you'll be working nonstop to increase that limit as fast as possible, to let as many people in when they want to get in as possible.

 


Comments

ketan
02/11/2008 03:26

simple and sweet!

Reply
Paddy
02/11/2008 04:15

isnt that a function of your workload?

lets say the site is 80% cacheable then it is okay but what if every request translates into multiple database queries, thats when an issue of scaling works.

maybe I am missing something.

Reply
Ivan Kirigin link
02/12/2008 23:31

We just launched tipjoy.com

We were techcrunched. The site did fine on one 2GB Slicehost slice. The front page was static, which helped. You can configure lighttpd or nginx easily to do this. I had a background process grab another page with the same content about the front page.

I'm writing a blog post about the details. I'm probing google analytics like an alien out in the farm country.

Reply
Ivan Kirigin link
02/12/2008 23:33

Ohh, forgot to mention: our biggest problem was bugs, not scalability. We launched as early as humanly possible. As Paul Graham says: if you are not embarrassed by what you launched with, you launched too early.

Reply
Ivan Kirigin link
02/12/2008 23:35

if you are not embarrassed by what you launched with, you launched too LATE.

And while I'm here, let me add: the feedback that you get will direct what you should work on next so much better than the next feature you think you need to implement. Also, fewer features mean easier to scale, right?

Reply
Au Pair link
03/19/2008 08:00

very nice web site. My English is not so good, so I do not understandt it well, but it seems very good. Thanks

Reply

Comments are closed.