Leaving Corporate

Socialbrowse all started with us wanted to help you waste less time online. Really!

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!

I just finished debuging a confusing issue on socialbrowse.com and wanted to make a quick note about working out of the django trunk.  I’ve been happily working from the django-trunk for over a year now and ignorantly updating whenever I felt the fancy or I found a new feature to utilize.

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.