Our initial project during Y Combinator was 8aweek, a browser extension that helps you limit how much time you waste browsing the web each day. 8aweek generated a large and passionate following and just before demo day, we added a new feature: the sidebar.

We recognized that there are multiple ways of saving time online. At first we focused on providing ways to limit the time you spend on casual browsing, but it’s also important to save time by making the good content quicker to find. We quickly hacked together a sidebar prototype which had several really cool features, including a slider which incrementally removed old links from the page you are on, leaving only the freshest content.

Expanding on this concept, we realized that the ability to quickly access links of interest could be a great way to save time, and thus we implemented a method of highlighting links that your friends also went to. The response to these features from the users we demo’d them to was enthusiastic enough for us to think hard about whether it fit within the 8aweek paradigm, or was deserving of it’s own product path.

If you’re reading this, you’re probably aware of the outcome, however at the time it required significant soul searching on our part. We had put so much emotional and physical energy into developing 8aweek, and our user base was nearly fanatical. We had presented 8aweek to over 150 investors at demo day, and were hot and heavy into the fund raising process, so the thought of switching gears onto a new product was daunting. But we also saw a unique opportunity in our new sidebar concept to develop an extremely innovative way of customizing the web as you browse. We were extremely passionate about the idea, and in the end, we recognized that we couldn’t pass up this opportunity, since it had the chance to really change how people browse the web. As a result, Socialbrowse was born.

The initial feature set of our Socialbrowse prototypes look nothing like the current product. Since our focus started with saving time, Socialbrowse initially was a sidebar control panel for altering the page you are on to find good content faster. Among other options, you could make old links disappear from the page, you could make the newest links “glow”, and you could remove Flash objects and images to declutter the page. The only aspect that remains today is the embedded user links, and that was the seed from which our current product grew.

As we continued to develop Socialbrowse, our focus evolved gradually from saving time to sharing and discovering content socially. We narrowed our feature set to support this focus more fully and the result of this process is the product you see today. Our goals are simple are to make it easy to share links and discover good content and we are rapidly iterating our product to this end. As we continue to grow, the product will evolve based on our user’s feedback and hopefully become a must-have extension to every browser. And if you find you’re spending too much time on Socialbrowse - well, there’s always 8aweek!

Django is under a great deal of development by its very active community and awesome new features are added all the time.  There hasn’t had an official “release” since March 2007 and there have been so many improvements that it is a huge disadvantage to not work from the trunk. A few people criticize the slow release process but most are content with the the historically very stable trunk.

The issue I had, however, was with dealing with backwards incompatibility.  I had never run into an issue where my newly updated trunk would not run the code that worked on an old version.  I was so confident in the trunk in fact that it didn’t occur to me for a full hour that the issue may have been with the Django update I had done the day before and not with the large chunk of my own code I had just loaded.It was really a brain dead, but easy to make, mistake.

Too confident in Django I updated mindlessly on the live server before I tested on the development server.  Luckily it wasn’t a major issue.  For about 2 hours while I was cursing and testing, our users couldn’t change their profile pictures.  After realizing it was nothing I had done the #django IRC was quick to point out the new file upload changes.

Moral of the story:  Watch out for backward incompatibilities and make sure your development and live servers are on the same revision.

1.    Other than an obnoxious sign up process its not that hard to get up and running a basic app on EC2 (1 - 5 hrs)
2.    The HD space isn’t yet persistent (guaranteed to be around).  You get about 16MB Update: 10GB of persistent info that will stick with your instance and then many GB of storage attached as your /mnt drive.  It has happened (though never to us) that everything on your /mnt drive could spontaneously disappear.  This means you need to keep a DB backup.  You should be doing this anyway though.  Also Amazon is soon releasing tools to make an instant image of your /mnt drive, which might make the whole persistent thing a virtual non-issue.
4.    Because of this you need to put all of your data on your /mnt drive, including .log files.  This means you’ll have to change the default locations of your db and log files for apache.  As you run your app keep an eye on your /root dir’s with “df -h” and make sure its not growing.  If it is growing you’ve got a stray log file somewhere and need to get rid of it or you’ll hit your 16MB max quickly and your server will go down cause your apps can’t write anything anymore and you will be confused for a long time.  We learned this one the hard way :|.
5.    Use the FF extension to handle your instances.  Its far from perfect.  It doesn’t allow you to name the instances, and the ssh functionality doesn’t work for Mac’s as far as I’ve been able to figure out.  But I think its a lot better interface than the command line tools.  http://developer.amazonwebservices.com/connect/entry.jspa?externalID=609
7.    The promising ability of scaling up and down based on demand isn’t easy.  RightScale offers some expensive tools/service for this.   There’s also Scalr, which is an open source system already bundled into Amazon Images for you.  I have yet to try this out.  It sounds promising.  If you’re just scaling to a hand full of servers (most cases) its easy enough to setup a load balancer such as HAProxy or nginx.   With notes from my friend Justin I wrote a cookbook for setting up HAProxy previously.
8.    Images taken from a Small instance cannot be loaded on L or XL instance, and vica versa.  This is becasue small instances have a 32-bit architecture and L and XL instances are 64-bit.

Good luck!  I’ll hopefully be posing a few more guides soon.

Updates 5/15:  This article was pretty much just some notes posted to the web for a few friends.  I didn’t do a lot of fact checking and have had the following facts checked/corrected for me.

The “got about 16 MB” estimate was  horribly wrong.  You can specify a bundle size up to 10G of free space in your bundle. The point is still the same though.  Put all growing data in your /mnt dir.

Rightscale should not be referred to as “expensive”.  I’m sure they’re more than worth their cost.

The latest version of Elasticfox (which I need to get) now has ssh support for macs.

I am an idiot and left out points 3 and 6.  This post actually only has 6 things you should know about Amazon EC2.  Never trust numbered list elements while editing a post.

The cookbook is mostly an abbreviation of the setup instructions for reviewboard.

Install Dependencies

sudo apt-get install build-essential python-dev memcached libmemcache-dev python-dev

Install cmemcache

Note, you might want to check for the latest version.

wget http://gijsbert.org/downloads/cmemcache/cmemcache-0.91.tar.bz2

tar -xvf cmemcache-0.91.tar.bz2
cd cmemcache-0.91
sudo python setup.py install

Running

Here are some instructions on running memcached. The following example runs memcached with 2G of memory listening on port 10.0.0.40 port 11211.

memcached -d -m 2048 -l 10.0.0.40 -p 11211

That’s it! If something went wrong or you’re a compile junkie you might want to install libmemcache from source, instead of using the apt-get.

 Testing

After running you can test with the test.py file provided in the download.

python test.py

Install libmemcache from source

If you’re not on a debian distribution and can’t simply use the apt-get install libmemcache you can install from source w/ the following steps.

wget http://people.freebsd.org/~seanc/libmemcache/libmemcache-1.4.0.rc2.tar.bz2
tar -xvf libmemcache-1.4.0.rc2.tar.bz2
cd libmemcache-1.4.0.rc2
./configure
make
sudo make install

Your future is important. Treat the application accordingly. Y Combinator is not a 3 month and out program. The 3 months is just the beginning. After that, you will continue to build your product, find investment, hire employees and create an actual business. This process will take years! This is a big decision and will change a large portion of your life, so don’t race through your application as if you’re trying for a summer job at McDonald’s. Spend the requisite time thinking through your idea, understanding what you are looking for out of YC, and preparing mentally for the long haul of startups. If you haven’t taken the preparation seriously, the application will show it, and you probably won’t get an interview.

Start early. If you haven’t already begun your application, do so now! It’s due on April 2nd, and you probably should have started at least a month in advance. There’s certainly been cases where founders have been accepted with a last minute application, but why risk it? The longer you can think things through and iteratively improve your application, the better chance you’ve got.

In fact it’s good to approach the application the same way you approach startups: release early and iterate. In this case, releasing merely means writing an initial version of the application draft. Don’t try to be perfect on your first draft. Just get your thoughts down in order to avoid writers block. Trying to word everything perfectly will just slow you down and make every sentence feel subpar. Typically if you just sit down and type it out, it’ll end up being 90% perfect anyways, and then you can tweak it as necessary.

Write alot, then erase alot. On some of the application’s questions, the 120 word limit can feeling very constraining. I would advise writing all your answers in as many words as it takes to fully answer the question. Then go back and cut whatever is not completely necessary in order to get it down to the limit. It’ll be painful, and you’ll need to remove sentences that you probably felt were critical, but ultimately it’ll leave you with a very succinct answer. It’ll be much cleaner and concise than if the constraint wasn’t there. This technique, rather than aiming for 120 word answers from the start, forces you to compress everything you’ve got into just a few powerful statements per answer.

This is actually very analogous to Demo Day. Each startup gets just 7 minutes to convince investors that they may be worth investing in. You can imagine that 7 minutes is not very long to show your product, demo all the features, describe how you’ll make money and discuss your competitors. But that time constraint has a remarkable effect: it forces each startup to be extremely focused on getting their message across quickly and clearly: what they do, why they are different, and how they will make money. Talking to some of the investors afterwards, they were in awe at how focused and polished the pitches were. They are unlike all the typical convoluted presentations the investors see. The time constraint forces you to cut the fat, just as the word limit does on the application.

Stand out. The YC partners will see 500-1000 of these applications. What will make them pause on yours and say “let’s find out a bit more about these guys/gals?” You need to identify what is unique about yourself and your accomplishments, and focus on these. Don’t water down your application. Find what stands out about you, and let that information stand out within the application.

Be Honest. Some of the questions on the application might seem tricky, as if it’s a riddle that must be cleverly approached. But the questions aren’t tricks, so answer them honestly. People are accustomed to trick questions, probably due to their experience with college adminission essays or job interviews. But YC doesn’t operate like that.

One question from the application that many people assume is a trick is “what is the minimum you’d sell your company for at the end of YC.” There isn’t a particular answers that YC wants to see, so don’t over analyze it. Just be honest, whether it is $2 million or $20 million. I suspect PG and company just wants this to serve as an exercise for you and your co-founders, so that you get on the same page with each other regarding the hard questions that could split you up down the line.

If you’re fortunate enough to get into YC, you’ll realize quickly that the questions on the application are much like the YC partners themselves. There is just no BS involved. When they work with you on your startup, they don’t play games or sugar coat their opinions. They are straightforward and honest, and they expect the same from you. It’s really a shame this modus operandi feels so foreign.

Be your own critic. This relates to being honest with yourself. I know that all founders consider their ideas their babies. But you can’t allow that emotional attachment cloud your perspective and prevent you from seeing your ideas’ drawbacks and weaknesses. Look at your idea from the perspective of another founder, or a random person in middle America. Tear away all biases you have and force yourself to ask the tough questions: How is this really better than similar products? Will anyone actually want this? How will I keep a step ahead of the competition? Don’t fall in love with your idea too early. By finding the weaknesses, you can brainstorm solutions to them pro actively, and this will make it much more convincing on the application.

Have a good team. This is probably the most important thing. You’re going to be competing with the best of the best for a spot in YC. Don’t go into this competition with subpar team members otherwise you have no chance! The YC partners see applications from the top technical talent in the world, so if you just load up your team with friends who you think it’d be fun to work with, your application will look weak in comparison. Each person on your team should be a superstar who adds obvious and unique value to your application through their credentials and achievements.

You’re going to go through alot of hard times in your startup. You need people who can weather the storm and forge ahead day after day. You’ll be wearing alot of hats and learning a hundred new things per day. Every person on your team needs to be hungry for knowledge and success.

Conclusion. I’m not personally part of the decision making process, and I don’t have any inside information about how these decisions are made. But from observing how PG, et al operate, and from seeing what makes the YC founders group unique compared to other people our age, I’ve been able to infer how a successful application would be written.

So take another look at your application. Find what stands out, focus on that, be honest, trim the fat and cross your fingers! And my most important piece of advice: whether YC accepts you for an interview or not, proceed with your startup regardless!

Check it out.

Why is Y Combinator funding both of these companies, does this create conflict, and are 8aweek and RescueTime really that similar? We get those questions alot, but we’re alot more comfortable with the situation than outsiders expect.

Arrington is right that it’s a bit curious that both 8aweek and RescueTime are backed by Y Combinator in the same funding cycle. But what makes this situation unique isn’t just that 8aweek and RescueTime are in the same space, but that there are very few other competitors in this space. In that sense, Y Combinator will come out with a solid foothold in this market. For YC it’s a great investment, as they will be a part of two different approaches in what we feel is a large, emerging market. Since this is such a new market, there is easily room for multiple companies pursuing different strategies, and certainly there will be more competitors in the future.

The RescueTime founders are great guys, and we chat with them every week at the YC dinners (and even swap some trade secrets). It’s hard to deny that we are competitors in a sense: we operate in a similar market! However, the degree to which we compete is much smaller than most people suspect. In our discussions with Tony, Brian, and Joe of RescueTime, we’ve shared strategies, product roadmaps, infrastructure tips, and survey data. This is far from the Microsoft/Google relationship most people expect.

The ways in which these products differ, and will continue to strategically diverge, is most obvious when you examine the respective companies’ tag lines:

Rescuetime - Ridiculously Easy Time Management. RescueTime is a very polished and effective tool for managing your time. You can break down your computer usage by category, and slice & dice the resulting data from every angle imaginable. This lets you discover how you spend your computer time each day, for instance to compare the amount of time you spend on web design to your blog writing. RescueTime also allows the ability to set goals and alerts to manage your time.

8aweek - Save Time Online. 8aweek, on the other hand, is less about time management and more about time saving. 8aweek’s feature-set is distinctly focused on saving you time when you’re using the internet. Yes, it tracks habits and displays your usage in interactive and pretty graphs, but it does so from the aspect of identifying time wasting websites. You can then add the biggest time wasters to your restricted list in order to limit the amount of time you spend on them. The real value of 8aweek is not in simply observing your web usage, but changing your habits to make you more productive.

There is certainly overlap in our products’ feature sets. Just as RescueTime’s goals and alerts extends into 8aweek’s core features, our habits tracking is similar to their base functionality. However, when you examine how these features are actually implemented, it’s clear that they uniquely support each products’ core focus.

To a great extent, having overlapping products can provide each company with their own competitive advantage. We have a constant (or at least weekly) reminder to focus on the value our differentiation provides. That’s an important point for any business, but it’s also something that is often forgotten in the rush to bloat a product with features. We recognize the value a time saving toolbar brings that a desktop time management application cannot, and vice versa. This forces us to focus our development and marketing on our product’s unique value-add — those aspects which cannot be easily duplicated by our competition. This constant obsession with competitive advantages is what will make our product great. In the case of 8aweek and RescueTime, having a competitive advantage is not mutually exclusive - it’s beneficial for both of us.

As our respective products continue to evolve, the differences will become more defined and apparent. The different approaches will manifest themselves in the subsequent feature sets. In fact, many Y Combinator founders already have installed both 8aweek and RescueTime, using them for separate reasons. And we’ll be rolling out an exciting 8aweek feature in the coming days that’ll provide a clear demonstration of just how different these products are, and will become.

HAproxy is a pretty sweet tool but currently has little written about it so installation and configuration takes reading a large text manual. Here though is a basic setup that should work for most cases.

mkdir /opt/haproxy
cd /opt/haproxy

#Download latest version from http://haproxy.1wt.eu/download/1.3/bin/ e.g.
wget http://haproxy.1wt.eu/download/1.3/bin/haproxy-1.3.14.2-pcre-40kses-splice-linux-i586.notstripped.gz -O haproxy.gz

gunzip haproxy.gz
chmod 700 haproxy

Now you have HA proxy installed but need a config file. Make a new file called /etc/haproxy.cfg and add the following contents.

global
log 127.0.0.1 daemon debug
maxconn 4096

pidfile /var/run/haproxy.pid
daemon
defaults
log global
mode http

option dontlognull
retries 3
option redispatch
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000
listen webfarm <HAproxy host ip>:80
mode http
cookie MYSITECOOKIE insert nocache
balance roundrobin
server app1 <server1 ip>:8080 cookie app1inst1 check
server app2 <server2 ip>:8080 cookie app2inst2 check
server app3 <server3 ip>:8080 cookie app3inst3 check

This config file sets up session based balancing; meaning HAproxy will inject its own cookie into each person who visits the load balancer. Then every requests the person with that cookie makes from that point on will get directed to the same server! This is most important for apps with content heavily based around user information. Without it its really tough to make use of local caching.

Make sure you change all of the parameters inside <> brackets. You can add or remove servers by editing the “server” commands. I think you can see the trend there :). Also you’ll want to change the MYSITECOOKIE, which is the name of the cookie that HAproxy will inject and the variables app* and app*inst* are made up. You can call them whatever you want.

You should also notice that in this setup HAproxy is listening to port 80 ( <HAproxy host ip>:80 ) and that its redirecting to port 8080 on the re-direct servers (<server1 ip>:8080 ). This is because often one of the re-direct servers is usually the same as the HAproxy host. Also its not a good idea to have random IP’s that aren’t directly linked to your domain to be hosting your app on port 80.

So, next we have to change your app instance to listen to port 8080. I’ve only done this with Apache2 and will only go through those steps. Its very simple and is probably as simple with other servers. You need to edit your ports.conf (often found in /etc/apache2/ports.conf ) and add, or change the following line at the top.

#ports.conf
Listen 8080

Save it, restart Apache2, and that’s it.

Lastly here are the directions for running the proxy. You could bundle these in a script but I use them so rarely I didn’t. There is one command for kicking off the proxy, another for verifying a new configuration file if you make an update (for when you add or remove a server) and finally a third that will dynamically reload your new configuration.

First time start:
/opt/haproxy/haproxy -f /etc/haproxy.cfg -p /var/run/haproxy.pid

Verify a valid configuration:
/opt/haproxy/haproxy -f /etc/haproxy.cfg -c

Dynamically reload configuration:
/bin/sh -c “/opt/haproxy/haproxy -f /etc/haproxy.cfg -p /var/run/haproxy.pid -st $(</var/run/haproxy.pid)”

I’m no expert. Like I said I got most of this from my friend Justin (Thanks Justin!). But it was a pain sifting through the manual and I thought others might benefit from these notes. For more information visit the HAproxy docs.

Note: Interestingly this post by Justin.tv promoting Nginx over Pound just made it to the top of Hacker News as I was finishing. I want to add my recommendation of HAproxy. I also tried Nginx but ended up going with HAproxy. There is certainly more articles on using Nginx but it is more difficult to set up session based balancing.

The Zenters were just a couple of guys with some work experience similar to Zack and I. But they must have had some serious skill since they were apparently kicking Google’s butt at the Powerpoint game, or at least were offering some pretty novel aspects, because they were acquired just 6 months after they started YC.

Lines of code is far from and end-all indicator of startup success. Especially when ignoring the little things like how much code was re-written/discarded, which languages/frameworks the code is in, comments, spacing between lines, the amazing roundness of the numbers 40,000 and 3 months, etc…. But there seemed to be a high correlation with the Zenters, and its something at least so I decided to see how we stack up.

If your files are all in one directory you can use a simple “cat * | wc -l”. We have a pretty big maze of directories however so I wrote this quick python script to walk the directory structure and find out for me. I wrote it so it’d be relatively easy for others to use. There are two variables at the top of the file where you can include directory names to ignore and characters in files that will exclude them from being counted. This way it won’t count the dirs with code we didn’t write, compiled files, svn repositories, images, copied files that emacs leaves behind, etc.

The results: 20,010 lines of code in the 53 days we’ve been working. Yes, I included the code in this script to break 20,000. Assuming we keep up our pace for the next 38 days (which might be unlikely due to demo day and investors) we’ll be at 34,511 lines for the 3 months. Crap! Just short!

Also, assuming we keep up that pace, I’ll be dead. A fact that Zack is disturbingly unconcerned about.

But kudos to the Zenters. You guys rock.

You can test yourselves to see if you can keep up with the Zenters. Download the script into the root dir of your source files. Open it up and edit the excluded_dirs and exclude_files_containing variables for your needs. Then run it: python line_cnt.py