On August 26th, 2006, Tucows was the winning bidder in the widely discussed (Techmeme, digg.com, Stowe Boyd) eBay auction of the web-based calendar application Kiko.

Why Did We Buy Kiko?

While there are a lot of little reasons, I'll cover a few of them in a moment, there is really one big reason why we bought Kiko. We needed the functionality, quite desperately, inside of our email platform and it was going to take us a long time to get it. Especially at the level of sophistication Kiko has.

The Calendar Function

Most webmail platforms have a calendar but very few of them are ever used. It is quite simply a crappy user experience. We as users have a problem with shared calendar inside of Tucows and because we are a mixed-desktop environment we are not able to go with the expensive-frustrating-functional Exchange Server solution. At times there have been real pushes for this internally but I have pushed back and insisted that anything we do with a shared calendar be open standards. There is not much.

We all believe that a calendar is a very important function in the messaging suite for small businesses. Given that people don't want to maintain separate services for personal and business use, and because the line between personal and business services is getting blurrier, we felt this functionality was a big hole for us.

So why didn't we build it? Well the short answer is we have so many things to do in general and so many exciting things to do with email in particular that it was just not going to be possible until at least Q2 of next year and even then the plan didn't really excite anyone around here. It looked sort of like the next-gen of our current offering. Had this not come up we would have probably stayed the course and looked to catch a break. When it did, we quickly went through a simple calculus.

The Important Question

What would we pay to have a kick-ass AJAX-based calendar available now?

When I am dealing with quick, complicated decisions I really like to boil them down to a simple abstract construct. Yes there are a huge number of shadings around that question but at its simplest that is the essence of the decision. What was the value to Tucows of the time and the certainty? Of being in the market with this functionality six to twelve months earlier than otherwise? What was the value of having it be good for sure? Even if we threw it away in six months (not that we plan to do that)?



What I can tell you for certain (and you'll be able to hear more details in an upcoming podcast) is that it was more than we paid!

This Situation and Tucows

From the time the auction was announced, there was great discussion online about the value of Kiko to a buyer and much of it was both accurate and confirming. Justin and Emmett (see them being interviewed by Alan Wilensky here, here, here and here) were absolutely right in determining that Kiko was a feature not a business. We think they were absolutely right in assessing that integration with email was key and that the greatest value here was to someone with a suite of services to integrate with. We felt that this was going to be 2-3 man-years of work and they confirmed that. All of this made us more comfortable in the short period of time that we had to make our decisions.

There were also some interesting facts that were specific to Kiko that made it work for us. It was clear from their posts and such that Justin and Emmett were no longer passionate about the calendar space and were excited to do something else. They felt, and we agree, that this was worth much more with them along for the ride. Probably by a factor of ten. It would have then attracted a completely different type of buyer. We would not have paid that premium for the people. Not that they aren't worth it. Just that our financial calculus was different. This probably kept some of the natural buyers out of the process.

We also did not need a huge base of retail users. They are nice and we will provide them with a great home but if this had been much of a success outside of Mike's 53,651 it probably would have attracted more financial buyers or domainers and the price might have ended up more than we were willing to pay. It is worth noting here (and we also talk more about this in the podcast) that there was clearly interest in the domain name and the traffic. We will certainly monetize that as it is a space we know well, but we also may choose to sell the name off as it is not core for us. Either way it is another place where we, more than most/all other buyers who would be interested in the calendar functionality, will be uniquely able to take advantage of the assets.

In a nutshell, this was the kind of deal where we were buying exactly what they were selling. That makes for good business and, by the way, is too infrequently the case with Internet services.

Other Benefits

As we dug deeper there were a number of other little benefits that made this seem like a great fit and got us comfortable pushing ourselves a bit on the spend.

I will call out a few of these, but this list is not exhaustive:

Global User-base - For some the non-US customer set and things like language support may not have been seen as benefits. For us they were a very nice addition. Our business is extremely global with customers in over 110 countries. We have a large European business and a large South American business. We have plenty of customers in Asia. The customers and languages that come along with Kiko are a nice benefit for us.

Mobile Integration - Kiko has a very impressive set of mobile carriers they integrate with. We were blown away when we dug into this. It will be nice to have that functionality for the calendar. It will be even nicer to have an existence proof for making the rest of our services more mobile. We are just starting to experiment with mobile around the edges of our business and this will help things along.

Nice AJAX Implementation - Kiko is a very nice use of AJAX, especially in a lot of the underlying thinking. To me, that is not about technology, but about making a web app behave more like a desktop app. Learning how this worked within Kiko and having to maintain this code base will be very good for the rest of our services. Again, there is a nice broad application of a benefit to be taken advantage of.

Conclusion

First and foremost this was about better/faster. We were able to get a key feature done well, and done now. In my view we were lucky with a number of the small things that made this happen. The people were not part of the deal which held down value for one group of buyers. The retail user base was real but not too large, which held down value for another group of potential buyers.

There were also a number of side benefits which are important in any good deal. The global user base and language support, the mobile integration and the nice use of AJAX are three examples.

All in, we are quite excited about this, we thank Justin and Emmett for all their hard work, we look forward to giving the existing customers an ever-improving user experience and look forward to bringing a great shared calendar to the millions of end-users and thousands of partners who use Tucows services today.