I remember reading about and signing up to LibraryThing sometime in 2006. The site was simple, functional , and I liked it. At the time I equated it to del.icio.us for books (it is typically referenced as the flickr for books), taking on a specific task for which I generally used Amazon and wish lists. With my recent thoughts on building web apps, I had some notions about a books and recommendations, and came back to the site.
LibraryThing is a virtual bookshelf management application, with natural social extensions for organisation, discussion, and recommendation. Basically, if you read and have a modest personal library, then it is defiantly an application that you want to try, and most likely subscribe.
As a case study web application, LibraryThing is cool (interesting) for a number of reasons:
- I was hacked together by a lone developer in a month (circa 2005)
- It was hacked together to 'scratch an itch'
- It was designed to make money from day one
- It is narrow
- It is successful
Success undoubtedly came from the real need (for both the creator and users) that the narrow application fills. The fact that the inception and creation of the application are attributed to a lone web developer is inspiring. The point that I really latched onto was the smarts of Spalding to withhold some features and promote a simple subscription service.
Unlike the unbounded and useful bookmarking service delicious, the LibraryThing service imposes a simple limit on the number of books and displays ads, both of which are removed when the user buys a yearly or lifetime subscription. This is important, firstly because without this simple mechanism the site would likely have gone under (how did delicious survive? VC?), and secondly because people want to pay for a good service. As such, LibraryThing clearly is the flickr for books as it uses the same freemium model that flickr users on top of a great product.
LibraryThing, more than flickr, is an strong inspiration as a subscription-based web application for me. It's the kind of narrow problem I would like to solve, it is the model I would like to use to pay my rent, and it can be (was!) achieved by 'a guy like me'.
4 comments:
Love it. My Amazon wish list is now in the import queue.
Like the model too. I'm also eyeing off the API.
Am I allowed to comment? :)
Thanks for all the kind words. I'm not sure I deserve them, but thanks.
Some thoughts:
1. The "narrowness" of the initial service is true enough, but LT has generally eschewed the "underdo" idea of Jason Fried et al. As it stands, LT is a shockingly baroque web ap.
2. When LT started everyone, including myself and my wife, thought it was a pretty edge idea. What could the demand be? How many people wanted to do this? 100? 1000? Surely it would hit some ceiling and that would be it. That it was a good idea, that the core idea hit other ideas and that it would to some extent grow its own demand weren't clear.
3. Self-funding may be great for the first entrant, but VC funding has been kind to later entrants—which is why LT is now in a dog-fight with two competitors. It is hard to self-fund and to scale fast enough—both technology and people—to put blue water between yourself and the sudden entry of a very well funded rival.
Anyway, interesting read. Let me know if you ever want to chat—about your projects or whatever.
Relevant post on YC titled Ask YC: Projects that inspire you. I added LT.
Also Tim, cheers for the elaboration. Your initial uncertainty for the project is comforting :)
I'm curious how a "lifetime subscription" model would work for such a small one-time sum. What would be the event that would trigger another payment from that user? Would they be asked to pay again in, say, three years after the service went through a few versions?
Post a Comment