I was recently thinking about the changing business model for many brick and mortar stores, like Best Buy. Where Best Buy used to be price competitive, they now charge a steep markup in-store. People making these purchases seem to be mostly those unaware of the true price. I occasionally purchase from their stores as well, when I absolutely need a physical item and can not get it shipped. Chris had the pleasure of listening to me vent about the absurdity of purchasing a $25 ethernet cable the other day.

Basic economic theory holds that competition should put downwards pressure on prices to where they approach equilibrium, and are fairly close to the cost of manufacturing. Yet this is not happening for ethernet cables. Why is that?

When you boil it down, it seems to be convenience -- you're able to purchase the physical item when you want it, and examine it before you purchase it. Going further, though, convenience doesn't only apply to in-store items.

Weebly is a great example of the power of convenience. When we started off, we heard "Oh, web hosting... that's a commodity" quite a bit. Most people considered it a "solved" problem, and quite boring. But the problem of designing visually appealing content, uploading media, and hosting web pages was far from solved, and a simple, easy to use solution gained quite a bit of traction fairly rapidly.

Which begs the question: "How do you model convenience?"

When analyzing competition, it's quite easy to model out all of the service characteristics, such as features and price. In fact, if you compare Weebly to several horribly outdated web site creators, the feature list might not look that different. The user experience, on the other hand, would be. Where Weebly shines is its simplicity and ease of use. Or, more simply: convenience.

Hopefully, someone with experience could shed some light. How do you model for convenience?

In a couple week's time, the teams YC has invited will be flying out to Palo Alto for a quick, shotgun style interview that they'll base their funding decisions on.

If you've been lucky enough to get invited, here's a bit of advice on what to expect and how to get through it successfully.

What to expect

You only have 10 minutes, which is a surprisingly short amount of time to discuss your business. You won't have any powerpoints or presentations, but you should have a demo. You'll start off, talk for about 15 seconds, and instantly get bombarded by questions for the next 9 minutes and 45 seconds. It's easy to get off-track, so you'll need to answer the questions quickly while trying to steer the discussion on-topic. Don't be surprised if multiple simultaneous conversations end up breaking out (at one point during our interview, I think I was having 2 simultaneous conversations -- one with PG and one with Trevor, while Chris and Dan were having a separate discussion with Jessica).

What you want to accomplish

You have ten minutes to convince the group that:

(a) Your idea is pretty good (it doesn't have to be take-over-the-world good, but it can't be bad -- that reflects negatively on your judgement).
(b) You're smart, and are otherwise equipped to accomplish your goal.
(c) You can get shit done.

Preparing for the interview

Experiences vary, but our demo was a crucial part of our interview. It's very helpful keeping the discussion on topic, lets the team visualize your product, and, most importantly, proves that you can actually build what you say you can.

Having an idea is pretty easy, but actually being able to put it together with the right parts -- easy to use, decent design, smart UI choices, functioning feature set -- in a short amount of time is what will be the difference between your product launching or not. Not all launched products are successful, but all unlaunched products fail, so proving that you can get your product finished and out the door is important.

Code frantically to get some kind of working demo done before the interview. Two weeks should be more than enough to get something basic done. If you can't, or your demo is going to look like hell, I wouldn't bother showing it.

If you couldn't already tell, memorizing some kind of presentation isn't going to work too well. Sticking stubbornly to your guns is also not advisable. As others have mentioned, you want to strike a balance between being open to suggestion, and defending your opinions -- just be sure to defend the right ones.

Having said that, be sure you know your market in and out. You better know who your competitors are ("We don't have any" is not an acceptable answer), the history of the market (What previous companies were similar? Were they successful? If so, how did the exit? If not, how are you going to do better?), how you are realistically going to make money (for a 3 person company, at least $30,000/month), and a very good technical understanding of how you are going to get all this done. The YC application is a great place to start to look for questions to prepare for the interview.

Before the interview

Relax. Put on some music to get yourself pumped up on the drive over. Try not to be nervous (even though everybody is, to some extent). Investors make a lot of decisions based on their excitement, so get excited about your idea! It'll rub off on them. Get there a few minutes early to hang out with some of the YC Alumni. You can also practice your pitch, and get some quick last minute feedback.

After the interview

You'll get a call that Sunday with the news. Don't freak out if it's late (ours was almost 2 hours later than they said it would be, and I was nursing some serious stomach ulcers at that point).

If things are still the way they were, you'll only have one variable: what your valuation is going to be. Decide ahead of time what is the lowest valuation you'd accept (if there even is one you wouldn't), so that you are prepared to give an instant answer to PG when he calls.

After the call, take a few shots, call everybody you know and enjoy yourself! Then get ready to work your ass off and eat ramen for 3 months.

Note: If there are any Penn State groups interviewing this session, be sure to shoot me an email! I'd love to get together over a few drinks and hear about your idea.

There's one thing you'll almost certainly need when starting a company: other people's help. The right introduction at the right time can make a world of difference.

How do you get people to help you? If people's interests are aligned to yours, they'll help you out. Those people are called investors. There's another way to get people to help you: make them like you and want to help you.

This ties in with a more general problem that a lot of very technical people face: How can I be a fun person, someone that people want to hang out with?

I was born in France, lived there for seven years, then moved to Casablanca (Morocco) and lived there until I came back to the US for college. Having never spent significant time in the US, I wasn't entirely used to the socializing process when I got here, but I picked up a few simple tips by observing how some of my more popular friends acted. Since I actively did that, I made a mental note of each one. These could generally be summed up as:

"How do I make a good first impression and get people to like me?"

1- Always introduce yourself (with a smile). For some reason, this is really important and labels you as assertive, friendly and outgoing. Make sure you introduce yourself to every member of the group and look them in the eye when shaking their hand. Don't be impolite by interrupting someone, but having said that, there's something very weird about someone who stands around and doesn't introduce themselves.

2- Ask a question. There are a ton of really easy questions you can ask, depending on your social situation. These include general questions, like "Where are you from?" and "What do you do?" as well as more situation-specific ones, like "What company are you with?".

3- Listen to the answer. Keep an open mind and don't assume anything negative. That seems simple, but too many people end up hogging the conversation off the bat by talking about themselves, or judging the other person. However, everybody likes a pleasant person who asks about them, listens, and responds intelligently. They'll usually return the favor by asking about you.

4- Figure out another question to ask based on the previous response. If you can find a way to add some kind of rapport, this is best, like "Oh, you're an engineering major? So am I!" or "You work at Trulia? I have a good friend that works there!". At worst, you should be able to ask for more information: "You go to UCSB? What major are you?"

5- Ask another question. Rinse and repeat.

That's really all there is to it. Besides being generally beneficial to your social life, being a genuinely fun and interesting person has one important benefit to your startup: It makes people want to help you, even if they won't personally benefit from doing so.

In other words, if you get feedback that you're not very "sociable", it is a huge benefit for you to learn to be so. It's not something that everybody is born with, but it is most definitely learnable.

Was reading an interesting post by Seth Godin this morning about bounce rate called Silly Traffic. Google Analytics defines "bounce rate" as "the percentage of single-page visits". Which got me thinking -- what's our bounce rate?

The last time I calculated our bounce rate (before we installed GA), it was pretty good: about 50% of new traffic signed up for Weebly.

Traffic to Weebly.com is made up of about 40% new, 60% returning. Of the new traffic, a significant portion -- a little below 40% -- arrives from search engines.

I was quite surprised to log-in this morning and find out that our bounce rate is 33% for new visitors, and 20% for returning visitors.

On the face of it, this seems to contradict the beginning of Seth's article, that all sites see at least a 75% bounce rate from unfocused traffic, but I haven't had much time to think about why that might be.

What's your bounce rate?

You've built a cool product. Great! Now, you need to show it off to people. Usually, this is a demo: a quick, 5 minute tour around the product.

Giving a demo is a lot better than trying to explain what your product does in words. It lets people see exactly how things work, and is the fastest way to help them understand your product. There's also an important set of people that will be particularly interested in your demo: investors. When raising money, a good demo to investors can make-or-break the decision process. So how do you give a good demo?

When raising money for Weebly, our demo was pretty simple. We'd spend about an hour ahead of the meeting looking up the investor's website, downloading the pictures and text, and importing the template into Weebly. Then, we'd spend a few minutes to practice creating the site quickly. The end result: we'd recreate an investor's site "from scratch" in front of them in 3-4 minutes. It definitely had the intended "wow" effect.

How do you put together a good demo? Here are a few tips:

- It has to be short. It should take 5 minutes or less in person. An online video should be no more than one and a half minutes long.

- It has to look really, really cool. The demo is a visual tour, and your audience will be concentrating on what they can see. Your goal is to get them to say "Wow!" Fades and animations get annoying in the final product, but they can look really cool for a demo.

- Adapt your demo for the audience. In our case, we would tailor the presentation to the investor we were presenting to. The person you're presenting to should be able to relate perfectly to the need for your product.

- Use real data. Don't ever type in "asdfasdf" for a form field. It's so much easier to understand what an application does when you can simulate a real user. Junk data makes it much more difficult to understand the use cases. Make sure to pre-populate your application with real data that highlights the story you're telling.

- Don't demo all of your features. Just demo the ones that best show off your product and give the maximum "wow" impact.

- Follow one general topic. If you're going to switch themes, make that very, very clear. It's like driving a car: if you want to change directions, you have to stop the car first.

- Have an offline or backup version ready. The worst thing is having to fiddle with the wifi connection for 10 minutes, or something going wrong with your host/colo while you're presenting. You might only have one chance -- make sure to have an EVDO card in case wifi doesn't work, or a local version.

- Show your product in the best light. You can be realistic about the shortcomings later, if/when asked. Make sure to always show off your product, and don't ever purposely demonstrate any shortcoming.

Finally, be confident and excited! You've built something really cool, and you should be conveying that message to the audience. If you're not excited about your product, why should they be?

Do you take into account the hidden cost when making decisions? It's one of those areas where I used to fail miserably. I've learned to take it into account over the last couple years, but only recently was able to formulate the concept properly.

The idea goes something like this: Behind most obvious decisions is a non-obvious hidden cost, which can often outweigh the benefit of the "obvious" decision.

I stumbled upon a great real-world example in the drive-through to Taco Bell a few days ago. I realized that there was a flaw in the system: I could order, then drive up to the payment window, and not be able to pay. Taco Bell would likely throw away the food, and have to eat the cost. The system had a flaw. Engineers like fundamentally perfect systems, and that's a good thing.

But if an engineer had designed the drive-through, you would probably have to pay before they started making your food. Impossible to game, flaw destroyed. The problem is, what's the cost of the extra time involved in waiting until you receive payment before you start making the food? And what's the cost per meal wasted times the number of times that the customer is not able to pay? There's a reason they start making your food right away: It saves a ton of time, and people are able to pay most of the time.

Seems obvious, right? Then why do we still insist on requiring two password fields, one for verification? Or two email fields? Sure, a banking application might require this... but your average web app? You could look at it this way: What's the chance that someone will mistype both their email AND password, weighed against the drop-off in signups because of the extra form fields. You will drop a significant number of sign-ups with the added fields, but there will be a very small percentage of people who get both their email and password wrong.

Another pet peeve that PG originally pointed out to us: requiring email confirmation as part of the sign-up process. Email is notoriously unreliable, and often gets flagged as spam or not delivered. Why would you require an email confirmation as part of your sign-up process when there is a high probability that the email will never be received, and the user won't be able to sign-up? Maybe I'm in a computer lab and I get email on my laptop. Tough luck, I can't use the website now, when I want to -- I have to wait until I can check my email. Does that high of a percentage of people not supply their correct email address, that you need to require confirmation? And does having a confirmed email address outweigh the big drop-off in signups?

We've learned to take the hidden cost into account with Weebly. It can apply to across the board: Adding features weighed against the added complexity to your application, bootstrapping weighed against the loss in growth momentum, increased security weighed against the increased difficulty in using the application.

In a nutshell: each decision you make will have a negative counterpart. Even (and especially) the most obvious decisions. Figure out what that hidden cost is, and make sure it doesn't outweigh the original benefit.

I first started working on Weebly in February 2006. I worked for about a year on it with Dan and, later, Chris' help, and we launched a (very) early version of Weebly in mid-November 2006. We were TechCrunch'ed a few days later, and accepted into Y Combinator the same day. (On the morning of our YC interview, we woke up to discover we were on TechCrunch).

Weebly has been growing ever since then, gone through two complete visual redesigns, added numerous features, and doesn't even resemble the product we launched with at all.

Here's two of our graphs from May 8th 2007 -- five months after we moved out to San Francisco and had been working on the product full-time:

The first is a graph of our new signups per day, and the second is a graph of our total user count per day. I've annotated the top graph with what events caused the major spikes.

There's actually two very interesting things to note about the top graph: First, we had already closed our angel round at this point -- looking back, our investors placed a huge amount of confidence in us.

Second, the new users per day looks like it might actually be declining a little bit.

At this point, I'd been working on Weebly for about a year and a half, and we'd been launched for over six months. Judging by the graphs, you might think things weren't looking spectacular. This is the type of situation when people give up.

I've seen it quite a bit among startups -- they spend more time developing the product than they do running it after they launch it. Several have followed the same pattern: build, build, build, launch, quit.

But you've got to keep with it to gain momentum. It doesn't usually just build overnight, it takes time. Keep building your product, and eventually you gain momentum and a critical mass of people who know about you and tell others about you.

Now, here are the graphs from a couple weeks ago:

These graphs look a hell of a lot better. There's 2 things I'd like to point out:

- First, the "build it and they will come" mentality is a fallacy. You need to build something great and have distribution in order to succeed. And distribution is hard to get.

There are many ways to get distribution. One of those is through press. If you have a great product, the more people that find out about you, the more people will know about you. And they'll tell their friends, who'll tell their friends, etc.

Another subtle press benefit: you're getting links from a bunch of very highly-regarded sites, and this helps out your rankings in search engines quite a bit, which builds more traffic.

There are plenty of other good ways to get traffic too, such as engineering for viral growth, but press can have huge benefits for the right product.

- Second, in order to get people to use your product, you have to stay alive. This sounds obvious, but a ton of people spend 6 months building a product, launch it, and give up within 3 weeks.

Plain and simple, it's going to take time for people to start using your product -- there are exceptions, but it's generally not the norm. So you need to expect that, and be willing to give it time. If you give up within a month or two, your product definitely won't be successful.

Once you launch, people start to know about you. If you launch early, you can start earlier on the process of acquiring users. Don't launch with a crappy product -- launch as soon as what you have is better than what is out there. But don't wait for a perfect product -- launch as early as you can, get user feedback, and keep improving the product.

The most important of them all (unless you're trying to get launch press): Be launched. We have spent $0 on press for Weebly, but we've gotten some big mentions (Newsweek, Time, NBC, BBC). Half of the battle is having a product that people can write about -- if you're not launched, people won't know you're there. If you aren't launched and people are still trying to write about you, although it feels good to be exclusive, you're missing out on an opportunity that might not come again.

Here are ten guidelines on how to make your story interesting for the tech blogs/press and successful in general:

1) Make your story worth writing about. First, make sure you have an angle that is really exciting. If you need to, tailor your message into something that fits with an industry trend. Make sure you have a jaw-dropping demo and a clear value proposition. Basically, make sure your startup is legitimately newsworthy.

2) Launch your news on a Tuesday, Wednesday or Thursday. There's too much news coming out on Monday, so don't try to compete with that. But make sure not to launch on the weekend, because there's so much less web traffic on the weekend than on the weekdays. Tuesday or Wed is generally the largest blog traffic day, so those are preferable.

3) Put together a short list of bloggers that are appropriate for your product. Put in some time to research this. Don't include bloggers that wouldn't normally write about your story. Add three types of bloggers to this list, in equal proportion: The large blogs, that you'd love to get coverage from, the medium blogs, that might cover you, and the small blogs, that will probably cover you because nobody really approaches them for a story. It's like applying for college: no matter what, you should at least get accepted somewhere.

Even if you don't get on the large or medium blogs, the medium bloggers generally read smaller blogs, and will pick up good stories they find there. Likewise, the larger bloggers read a certain amount of medium blogs, and the story can bubble up if it is newsworthy.

4) Contact the people on your list a week or two before the launch. Make your email very personable, from the founders, but straight and to the point (their time is valuable). Your goal is to meet with the blogger in person. If that's not possible, you want to talk to them on the phone. If that's not possible, as a last resort, let them have an online demo of your product. Why? An idea and mission is much more convincing when delivered in person or over the phone by a passionate founder. You'll also have adequate chance to rebut any of their arguments against it, and you're much less likely to wake up to an article that completely missed the point of the company, or where the reporter ran into some bug in your system.

If you're just starting, though, and don't have any connections to get de-facto attention, you'll want to make it as easy as possible for the blogger to try out your software: this means you should have a direct link that requires no log-in or sign-up with pre-populated data that the blogger is able to play around with in 5 minutes or less.

5) Set a clear embargo date. We've found that sometime in the morning works best for blogs, like 10am PST. What is an embargo? It's a time after which the press is allowed to write about a story, but they're forbidden to write before then. Why set an embargo? If you don't set one, you'll end up with the grave shift post on Friday at 11pm, where no one will see it. The goal is to keep your post on the front page as long as possible.

Embargoes are actually a solution that works well for bloggers (even though some love to hate on it). Nobody likes to write about a story that is old news -- and old news can mean just a few hours old. You need to set an embargo to co-ordinate all of the major blogs, so that nobody scoops anybody else, and they all post about you (instead of just one). The way that Techmeme works, they all get to ride on the coattails of the story this way, too.

Don't feel the need to volunteer an exclusive -- if your story is newsworthy, everybody will write about it. Either way, you're much better off with coverage from 4 blogs than coverage from just one. Your goal is to pop up in every feed people read: then they can't miss your story.

6) Make yourself available. Before the launch, make yourself as available as possible. Give out your cell phone number, and always answer it -- even late at night or early in the morning. You might not get another chance to catch up with this particular blogger/reporter.

7) Make sure your product is ready. It's difficult to tell when a product is ready, but now that you're going to be receiving all of this press attention, make sure it's ready for the load. It's very likely that if your product isn't up to par, you won't get a second chance for coverage or attention. Not to say that you shouldn't launch early and often (you should), but as Paul Buchheit says, "launch your product if it's better than anything else out there."

8) Sit back, relax, and enjoy the attention. Congratulations! A large portion of the tech world's attention is focused on your startup. Expect to get emails from ridiculous people, and a few thousand sign-ups.

9) Don't panic when the attention dies. It's always tempting to fantasize that the traffic spike will stay. Except for in rare circumstances, traffic will die down and form a spike. That's ok -- you should at least have more people/day signing up than you did before the attention.

10) Cultivate relationships for next time. This is good life advice in general. If you meet with press people, work on cultivating a relationship at the personal level. A good friend doesn't only talk to you when they need something, and treats you like a normal person. I'm not advocating being fake with people, but showing a minimum level interest in them personally, sending emails when they change jobs, saying "Hi" when you bump into them at social events, etc, goes a long way. At best, you might become really good friends with them.

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.

I keep noticing startups (and larger companies, too) making some really basic mistakes that end up leading to a lot of downtime. Here's my list of 6 really easy things you can do to avoid major downtime.

1. Buy backup DNS service
This is so cheap it's a no-brainer. For about $15/year you can get a service that will constantly grab your DNS data and act as a backup if they happen to go down. Otherwise, when your DNS servers go haywire (it's happened to me and I've seen it happen to many others), you'll be stuck helpless for a few hours as people are unable to get to your site. [I've used No-IP Squared Backup, and Chris has used Nettica].

2. Buy a monitoring service
For $5/month, you can purchase a service that pings your servers every few minutes and sends you a text message if they go down. This is absolutely crucial, especially if things go to hell in the middle of the night, or any other time you might not normally be checking. Make sure to buy a service that monitors from at least 3 locations -- there's nothing worse than a few false alarms in the middle of the night, after which you won't get up for the real thing. [I've been happy with WebSitePulse -- their prices are a bit more expensive now, but you should be able to get them down to $5/month on the phone.]

3. Always make database backups before touching the database
It's one of those things you always consider and dismiss right before you bring the whole thing crashing down. Especially if you aren't making very regular backups (note: you should be), make sure to do so before you get your hands dirty. (Ever forget the WHERE clause? Not fun...)

4. Be VERY careful around power cords at Colos
Knocking out a power cord seems to happen consistently if you don't make a very concerted effort not to. It's extremely easy for a cord to jiggle a tiny bit, or for one moving server to pull on another cord in just the right way. Always plan out your server trajectories before you move them, or have someone to hold the power cords in. [Note: Why aren't snap-in power cords standard for rack mountable servers??]

5. Make your site functional in pieces
Even if your database is down, there's no reason your home page shouldn't still show, or any of your other static pages. There's a big difference from a user's point of view in between an otherwise seemingly functional site that shows a nice looking error message, and a site that spits out errors, is not accessible, or won't load at all. If Weebly's database goes down, users will see a polite "Sorry, something is wrong and we're fixing it right now" error message. Our site, blog, and all hosted user sites stay up, so a database crash just means that people can't edit their sites at the moment.

6. Use source management to roll out updates
We use darcs to manage our different source repositories, and it's a flexible and distributed system that works very well for us. Whatever you use, make sure you use some automated process to roll out updates (which doesn't include moving a directory and moving another in it's place, and, God forbid, manually diff'ing files -- there's always more to that than you anticipate). It's quite shameful to see pretty basic sites go down for hours (or days, or weeks) rolling out an update. If you're using Weebly while we push out an update, your session will automatically be refreshed without any loss of data, and you'll be up and running on the new version within seconds (with no downtime). [Darcs can be found at http://darcs.net/]

Those 6 items combined have probably caused over 80% of downtime I've been responsible for. What's your list?