I joined Twitter around Jan of 2008 (supposedly before 99.9% of today’s Twitter users).
Like most, it took me awhile to really get it…but once I did, I went full in.
I started building out lots of different systems and tools on top of the Twitter API and generally had a lot of fun thinking about new and interesting hacks around the data set that I could learn from and play with.
One of those early hacks was a system I called pu.ly.
For those of you that don’t know, in the early days of Twitter the feature set was super light…and in fact many of the features you know and love today (like @ mentions) were things that were entirely made up conventions from the users. One of those big initial gaps was alerting.
Once I started getting into Twitter, and gained a tiny following, I noticed that I was spending a lot of time checking in on the service throughout the day (because I wanted to make sure to be responsive to anyone who was attempting to chat with me).
I built pu.ly to do this monitoring for me, and just ping me with an email each time someone @ mentioned me…and then because I had fallen in love with the Disqus feature, I added the ability to directly reply via email and that reply would post to Twitter (if it was over 140 chars it included a link to the larger text on pu.ly).
Like most of my hacks, I initially built it to serve my own need…but released it out to the world with the thought that others might also find it useful.
And by chance, a few others did in fact discover it and find it useful (it even got covered/recommended in a Mashable article).
Still it never reached crazy traction, but at it’s height it did have a little over 1,000 accounts attached (giving me a mapping of twitter handles to email addresses) and was sending a good volume of emails every day.
The trouble was, from day one, I never really had revenue plan for it.
I thought it might work as subscription service, but I knew I wouldn’t pay for it myself (so I was hesitant to try and make others pay for it).
I also thought that I might be able to run some advertising in the hundreds of emails that were getting sent out (and of course offer the subscription option to those that wanted to turn them off).
But I never actually executed on either of these ideas.
Partially because I didn’t need the service to make money (though it was costing me a little bit to send so many emails each day) and partially because I was mostly focused on my other interests at the time.
Long story short, Twitter eventually came out with their own email alerts.
They weren’t as good to start (it often failed to send alerts or would send them really late), but it was integrated and more simple for the average user… and they had a team dedicated to improving it (the system is now *much* better than pu.ly was).
Twitter’s move into the space, along with my lack of focus on the product, made my decision to shut it down pretty easy on the surface…but in reality I did flip-flop on it for a few weeks.
When I made the initial announcement a handful of passionate users – that were not going to be properly served by the new Twitter version – talked me into keeping it going; but the writing was on the wall and I eventually decided it would be better to close it than offer an inferior product that I wouldn’t focus on.
Overall, you could look at pu.ly as something that failed or you could look at it as something that worked really well for a specific point in time…I guess I look at it both ways.
It re-affirmed my belief in the power of email and alerts (something I still build into almost all my products)…and it showed me that even small, niche tools when done for the right reasons, can build a small, passionate fan base (that would likely even pay).
It also proved that revenue doesn’t just magically appear…and that ideas around revenue aren’t very useful without execution (I should have built a subscription version/offering from the start, even if it’s not the version I personally was going to use).
But probably the biggest thing that it really taught me was that, you can build some really interesting and useful things via an API and on top of someone else’s data…but if all it does is improve their service, and you don’t really add any outside value (something that makes you an important player in the workflow) then you are at the mercy of the API provider.
If you prove that the hole is big enough, or interesting enough, it’s only a matter of time before they’ll fill that hole themselves (and if the hole isn’t big enough for them to want to fill themselves, it’s unlikely to be very profitable for you either).
Since shutting down pu.ly (and many of my other Twitter hacks), I’ve mostly moved away from building things on top of Twitter…I still like to offer account auth and account creation via their API (and I use Facebook’s API for that too)…but I no longer like to use it to build features that ‘fix’ something primarily for their users.
When I take advantage of APIs now it’s about my users first, our users second, and their users last…which is a little sad because it has nothing to do with servicing the users and everything to do with the business implications.
This post has received 39 loves.
Kevin has a day job as CTO of Veritonic and is spending nights & weekends hacking on Share Game Tape. You can also check out some of his open source code on GitHub or connect with him on Twitter @falicon or via email at kevin at falicon.com.
If you have comments, thoughts, or want to respond to something you see here I would encourage you to respond via a post on your own blog (and then let me know about the link via one of the routes mentioned above).