Mark Fletcher: Lessons Learned Birthing and Building Web Startups

This is part of my set of notes from the Startup School 2006 sessions at Stanford.

Mark Flecter is a two-time entrepreneur with two successful companies under his belt:

  • OneList: At the end of 1999 merged with Egroups, acquired by Yahoo in June 2000. Product is now Yahoo Groups, and has 140K users
  • BlogLines: Launched in June 2002, this company was totally self-funded. Put in a total of $200K from start to finish, build it using only one salaried employee, four stock-only compensated employees, and outsourced labor hired through eLance. BlogLines was bought in 2005 by Ask Jeeves.

Garage Philosophy

Mark has his own “garage philosophy” – secrets to success for startups:

  • Passion for the idea: He’s been driven by solving problems he has himself. OneList was driven by his need to have an easy way to set up a mail list. BlogLines was driven by the problem of having an enormous bookmark list that he visited every day. If you solve a problem that you have, other people most likely have the same problem. It’s easy to get enamoured by the technology, and do things because you can. Instead, focus on the stuff that interests you, solves a problem for you. This will be your life 24×7, so you’d better enjoy what you’re doing.
  • Cheap technologies: Design around the idea of cheap hardware and open source.
  • It doesn’t have to be perfect: Many people try to get it perfect before they launch. This should be avoided – launch early, launch often. OneList was really ugly at first, and missing huge chunks of functionality. Doing this kick-starts the “virtuous cycle” where active feedback from customers drive development. Half of customer support email sent to BlogLines are feature ideas. Also engages customers, ties them more to your service as you address their needs.
  • Moonlighting limits risk: He worked a full-time job when starting BlogLines – he had a mortgage to support.
  • Friends/Family funds: When you do raise money, look to family/friends. The longer you can go without raising VC funding, the better position you’ll be in. BlogLines didn’t take VC funding until they had a million users. This put them in excellent negotiating position.
  • Free services = less pressure: You don’t have to worry about high availability when you’re offering a free service. People will cut you some slack.
  • Hire a lawyer: When he did OneList, he used an online service to incorporate in Delaware. Ended up having to redo things entirely and in the end it didn’t really save much money or time.
  • Outsource to eLance/Rent A Coder: Althought Mark wouldn’t recommend outsourcing core pieces of technology development, it can still be useful. For example, BlogLines has a notifier application – BlogLines put together a proposal, posted it on eLance and had some guys from Kazakstan/Russia write the application to their exact specifications in two days. Ditto for translation services – they extracted all of the text, posted the proposal to eLance, and for $3500 had the service translated into 6 languages. Graphics is also a good place to try using outsourced labor. In general, Mark recommends making the proposal as specific as possible to guarantee success.
  • PR is cheapest marketing you can do: The only way to value your service is in the growth of your user base, and the buzz surrounding your service. Anybody can come along and be smarter than you, but they can’t copy your users. Focus on viral growth – motivate users to be your best cheerleaders. Make it valuable for them to have their friends on the service. OneList pulled people in because people created mail lists for their friends – you couldn’t create a mail list that didn’t encourage people to sign up. Also, PR is cheap. Find someone who can develop relationships with reporters. BlogLines had great press coverage, four write ups in the Wall Street Journal. PR person was working for stock!

Design Philosophies

One great resource that summarizes it better than Mark ever could: Amy Jo Kim’s presentation at Etech – Putting the Fun in Functional.

Technical Aspects

Software choices

  • Linux/Apache
  • C/C++/bash/python
  • DJB/qmail/DJBDNS/Daemontools (http://cr.yp.to)
  • ClearSilver (http://www.clearsilver.net)
  • Berkeley DB (http://www.sleepycat.com)
  • Memcached
  • Avoid NFS
  • Avoid table-level locking in MySQL
  • The faster your web site is, the more pageviews you get. Whenever BlogLines slowed down, they threw more hardware at it and saw 30% more pageviews, not from more users, but more use of the product from the existing users

Hardware choices

  • Dedicated servers v. Buying/Hosting: For BlogLines, they bought their own hardware. They had to find machines, the co-lo, and deal with the network issues. Thought the advantage is that it’s cheaper in the long run, but would not do this again in the future. Renting the machines is the way to go – it just doesn’t cost that much.
  • eBay is a great place to buy hardware – you can find several wholesalers who will put together any machine you want, even new hardware.
  • APC PDUs for remote power cycling
  • HP ProCurve
  • Avoid Seagate Ultra-SCSI drives – they had 50% failure rate
  • A good phone for SSH which allows remote problem solving. He’s been in a casino, in front of a slot machine, fixing a server from his phone!

Architecture Choices

  • Copying files v. Client/Server: The BlogLines News RSS Feed is basically a text file that they copy between servers; copying files scales infinitely, and is a good solution for a lot of things. Not ideal for everything, but something to consider.
  • Calculate on the fly v. Cache: BlogLines generated cached pages of user accounts for spiders to crawl.
  • Memory v. Disk: Notifications in OneList – they were keeping track of how many emails were sent to a mail list in memory.

Storage Choices

  • Relational DB v. flat files: Don’t underestimate the power of flat files. BlogLines uses subscriber information in a sleepycat DB, and blog articles are all in flat files.
  • RAID v. Redundant hardware: OneList was storing mail list articles on RAID, which doesn’t lose data in case of failure, but results in data being unavailable. With BlogLines, they replicate blog posts across machine, not just at the disk level, ensuring that even if storage failed, service was still available.
  • Linux Software RAID: Prefer software RAID over hardware

SysAdmin Choices

  • DNS round robin for web servers – no need for hardware load balancers
  • Hot backups for offline-processing
  • Worry about cooling at the co-lo. If you find yourself with a lot of hard drive failures, you should suspect a cooling issue. (Unless you determine, as they did, that Seagate drives suck).

Avoid making stupid bets

While working on OneList, he made bet that if they were successful, they’d have a big party and that he would shave his heads. They were successful – baldness ho!

Audience Questions

  • What is your strategy for choosing what to outsource? Choose isolated pieces of functionality that can easily be developed separated from the rest of the code. He has experienced disaster outsourcing core functionality. Put a boundary around what you will or won’t outsource.