TechUser.Net

How much was Kiko really worth?

The web calendaring startup Kiko's Ebay auction made headlines recently. Kiko never managed to come up with a viable business model to leverage its development effort and never generated any revenues. The lack of a business model, lack of funds to expand the development effort, relentless competition in the web calendaring space, and burnout from a grueling work schedule forced Kiko's founders to call it quits.

Kiko's assets were purchased by Tucows for $258,100. Tucows is well-known for its shareware distribution site, but shareware is not Tucows core business. Tucows primarily sells domain registration, messaging solutions, blogging tools, and similar services. It has an email platform which it markets to ISPs and businesses and it purchased Kiko to make Kiko Calendar a part of that platform. Kiko's founders are ecstatic with the price they got from Tucows; however, the bid data from Kiko's Ebay auction suggests that Kiko was worth a lot more than what Kiko's founders received for it.

The bid data combined with background information on the bidders suggests that bidders generally did not care about the Kiko domain and userbase, and the bidding was primarily for Kiko's codebase. Most significantly, almost all the bidders would have been happier with a non-exclusive license to Kiko's codebase that allowed them to customize and use/sell Kiko's software royalty-free.

Tucows certainly did not care about the domain and the userbase, and Tucows CEO, Eliott Noss, specifically mentions this in his Kiko purchase announcement Blog post and Talkcruch podcast. Eliott Noss does not say whether Tucows would have been willing to live with a non-exclusive license for the Kiko codebase, but there was little reason for Tucows to want exclusive rights to the Kiko codebase. Calendaring is just one feature of Tucows' email offering, and a non-exclusive web calendaring product would not have caused Tucows' overall email offering to become undifferentiated.

Identities of all the other bidders are not known but web forum posts and Google searches suggest that the bidders wswire, ogijun, and macrhino are based in China, Japan, and Sweden respectively. Wswire is a Chinese language portal and it likely was only interested in integrating a Chinese language version of Kiko with its portal. A Reddit comment thread reveals ogijun to be an AJAX and Ruby on Rails programmer who maintains a blog in Japanese. The business case for ogijun's bid seems to be the domestic Japanese market. Similar reasoning suggests that macrhino was primarily interested in targeting Swedish and adjoining European markets. As all of these bidders were interested in targeting niche markets, there was little rationale for any of them to attach significant value to the Kiko domain, the Kiko userbase, and exclusive rights to the Kiko codebase.

In fact, during Kiko's Ebay auction, Kiko founders received many requests for Kiko software licenses. Kiko's founders disclosed this information as part of an update to Kiko's auction listing. The update states:

Update (8/18/06): Kiko currently has no advertising revenue, but it has a pagerank of 7. Since this auction was launched, we've had quite a few requests by individuals wanting to purchase licenses for the Kiko software. While we don't want to pursue this ourselves, this might be a good way for a buyer of Kiko to turn around and quickly make his or her money back.

The strong interest in licensing the Kiko codebase makes perfect sense from the perspective of potential licensees. With exclusive rights to Kiko's codebase the buyer of the rights needed to takeover responsibility for software development/maintenance from Kiko's founders. This was highly undesirable as software development can get very expensive, and the expense is all the greater for highly interactive software like that of Kiko's.

To start with, the new owner of Kiko's codebase needed to have substantial in-house software development expertise in order to put together, motivate and monitor a software development team, and not very many businesses have such expertise. Apart from this, the new Kiko codebase owner needed, at the very minimum, a team of five developers to keep Kiko's software in usable form. The new owner needed to hire two experienced programmers, a tester, a usability specialist with extensive expertise in human computer interaction design, and a graphic designer. Worst of all, there was no guarantee that Kiko's codebase was in good shape and could be built upon by a team of developers unfamiliar with the codebase.

(It is true that Kiko got by with only three developers. However, startup founders routinely work 80 plus hours a week, and a business can not expect an average employee to put up such effort. Moreover, Kiko's developers got burned out by their work schedule and this was one reason they chose to quit.)

Had Kiko chosen to stay in the calendaring business to sell licenses, licensees could have depended on Kiko for feature updates, bug fixes, and software customization. This would have saved licensees anywhere from half a million to in excess of a million dollars in software maintenance costs each year.

Evidently, non-exclusive codebase licensing, if available, was a much more attractive option for the bidders who took part in Kiko's auction. This is a very significant insight, and it implies that the bid history of Kiko's auction is a very conservative demand schedule for non-exclusive licensing of the Kiko codebase.

There were eight verified bidders in Kiko's auction and the following table summarizes their highest Ebay bids:

Bidder Bid Time
powerjoe1998 $258,100.00 Aug-26-06 10:17:29
wswire $258,000.00 Aug-26-06 10:17:52
macrhino $200,000.00 Aug-26-06 10:17:32
eladsr57 $150,051.00 Aug-26-06 09:54:21
ogijun $113,777.00 Aug-26-06 10:11:49
robbkni $64,800.00 Aug-26-06 09:31:50
al_uminum $61,500.00 Aug-25-06 20:23:22
dvdy98 $55,643.00 Aug-25-06 02:25:55

From the above table one can derive the demand for Kiko software licenses at a particular price point by counting the number of bids at or above that price point. Table 2 summarizes the demand for licenses at several price points and also gives the potential revenue Kiko could have realized by pricing the licenses at the chosen price points.

License Price Demand Licensing Revenue
$250,000 2 $500,000
$200,000 3 $600,000
$150,000 4 $600,000
$100,000 5 $500,000
$50,000 8 $400,000

Table 2 seems to imply that a license price of $150,000 or $200,000 for the Kiko codebase would have maximized licensing revenues but this is not so. Almost all experienced Ebay shoppers tend to place their high bids just seconds before the closing of the auction in order to avoid bidding wars. This was the case in this auction as well. Unfortunately, several minutes before the closing of this auction, the item price had moved well beyond $100,000. Consequently, some potential bidders who were planning to bid around $100,000 never managed to bid. Therefore, at the $100,000 price point the demand for Kiko software licenses almost certainly exceeded five licenses, and Kiko could have realized a revenue of $600,000 or more at that price point.

Now Kiko could have realized a revenue of $600,000 at three very different price points. Fortunately, the choice of the correct price point is obvious. Kiko should have priced the licenses at $100,000 each. This price point would have reduced variability in revenue as the revenue would have come from a larger customer base.

Actually, Kiko could have done even better by employing market segmentation to divide up potential customers according to the price the customers were willing to pay. Subsequently, Kiko could have created different licensing packages to target the different market segments.

A simple such strategy would be this:

  1. Divide the market into customers willing to pay around $100,000 for Kiko software licenses and customers willing to pay significantly more than $100,000 for the same.
  2. Target the respective market segments by a basic licensing package priced at $100,000 and a premium licensing package priced at $200,000.

The basic package would consist of a license to the most current release of Kiko's codebase and nothing else. The premium package would include the codebase, access to bug fixes and future releases of Kiko's codebase for one year, and extensive technical support for product customization for one year.

With this strategy, the premium package is not only designed to pull more money out of the customer's pocket but is also intended to make the revenue recur. By going with the premium package a customer would save considerably in excess of $200,000 in software maintenance costs a year and the package is designed to claim a chunk of those savings. Essentially, the premium package is a one year software maintenance contract, and this is where most of the money is to be made. The basic package has a complementary role as it allows customers to evaluate and deploy Kiko's software at a lower price point and in doing so creates additional demand for the premium package.

The Kiko auction bid data suggests that a good market segmentation strategy would have allowed Kiko to sell four basic licenses and three premium licenses within three to six months time. Kiko would have earned one million dollars in revenue in that period and possibly a lot more over the whole year. Even better, a substantial fraction of the revenue generated from licensing would have recurred year after year.

For a calendaring startup just one million dollars in revenue a year is an impressive achievement. To put this number in perspective, Kiko would have needed to sell 50,000 subscriptions to its calendaring service at $20 each in order to reach the one million dollar figure. For Kiko selling this many subscriptions was not even possible as all of its traffic amounted to only 40,000 visitors a month.

With more than a million dollars in licensing revenue, Kiko could have earned a profit of half a million dollars or more, and done that even after expanding its payroll. Actually, Kiko would have done a lot better than the revenue numbers inferred from the Ebay bid data suggest. This is simply due to the Ebay bid data being a very conservative estimate of actual demand for Kiko codebase licensing. The Ebay auction ran for only ten days and most businesses need a lot more time than that to evaluate an opportunity. Additionally, businesses who were unable or unwilling to assume software development duties for the Kiko codebase stayed away. Also, not everyone who needed Kiko access to Kiko's codebase got to learn about Kiko's Ebay auction, and this was especially true of potential bidders outside of English speaking countries.

All of this implies that the true demand for Kiko codebase licensing may have been an order of magnitude greater than the demand implied by Kiko's Ebay auction data. Kiko could not have converted all of this demand to revenues, but clearly, growth prospects for the company were quite impressive.

For a startup, sustainable profitability in excess of half a million dollars, and good growth prospects imply a valuation in excess of $20 million. This suggests that the $258,100 Kiko's founders received for Kiko's assets was less than two percent of Kiko's true worth.

Kiko's founders could not have done much about this as they could not have arrived at the above valuation before the closing of Kiko's auction. However, the rest of the web 2.0 calendaring crowd is missing a trick or two.

The bid data from Kiko's auction is not only pertinent to Kiko, but is also relevant to all web 2.0 calendaring startups. The data suggests that codebase licensing is the ideal business model for web 2.0 calendaring startups. Unfortunately, none of the calendaring startups seem to have any inkling of this.

The web 2.0 calendaring startups are either waiting to be acquired, or are obsessed with making money by selling subscriptions and selling per user licenses. The subscription market some of the calendaring startups are eyeing is actually quite lucrative, but unfortunately, it is already owned by the likes of Microsoft. Not unexpectedly, none of the startups are having much luck competing against Microsoft and this is unlikely to change.

For web 2.0 calendaring startups, code licensing is a much easier route to profitability but the startups are not seeing the potential. These startups have always unconsciously and incorrectly assumed that the value of a codebase is inversely proportional to the number of licenses issued for it, and because of this assumption they believe the market for codebase licensing to be extremely limited.

The value of a codebase does have something to do with the number of licenses issued for it, but the relationship is not the one the calendaring startups are assuming it to be.

A business licenses a codebase in order to build new products and services around it. The new products and services create a competitive advantage for the business but they also inspire imitators and competitors to come up with similar offerings of their own. Naturally, the imitators and competitors are in a rush to get their offerings to the market and can not afford to go for long and expensive software development cycles. Instead, they also opt for codebase licensing, and in doing so stimulate demand for the codebase that was used to put together the offerings they are trying to match. This kind of cascade effect is not at all unusual and the Unix market has been shaped by tit-for-tat codebase licensing.

Clearly, the demand for the licensing of a codebase grows as licenses for it are issued, but to benefit from this effect a codebase needs to have healthy initial demand.

In the case of web 2.0 calendaring, the initial demand is there and Kiko's Ebay auction proves this to be so. The demand is primarily from businesses who need online calendaring but are unwilling to pay per user royalties as they intend to push the calendaring functionality to massive userbases. Typical examples include messaging solution providers, web-portals, social networks, and so on.

The best part about going with a business model centered around code licensing is that such a business model is immune to attack from the likes of Microsoft. Microsoft and other established players in the calendaring market are never going to opt for codebase licensing as doing so will cannibalize the sales of per user calendaring licenses.

Interestingly, even after having sold its codebase, it is still possible for Kiko to get back in the calendaring business. Kiko's founders should be able to get Kiko's codebase back in exchange for returning the auction proceeds and letting Tucows keep a license to the codebase. Tucows will be very happy with this trade as it does not require the functionality provided by Kiko's codebase immediately and such a deal will lead to significant software maintenance costs savings.

Unfortunately, even though Kiko's founders have an option of getting back into online calendaring, the option may no longer be all that lucrative. Kiko's founders needed to recognize the potential of codebase licensing on their own in order to maximize licensing revenues. If they had come up a business model based on codebase licensing on their own, they could have kept it private. This would have allowed them time to raise funds, organize a strong marketing and sales effort, tailor their offering to the demands of licensees, and most importantly, grab substantial market share before the competitors realized the potential of codebase licensing.

With a solid business model for online calendaring now public information, it is almost certain that some fraction of the desperate online calendaring crowd will opt to go with codebase licensing. Consequently, Kiko can no longer hope to have a head start over the competition. For Kiko, competition in the codebase licensing space will mean lower license prices, lower market share, lower revenues, and a drastically reduced valuation.

All of this suggests that, although Kiko's founders could have done better, they need not resent exiting the calendaring market too much. Doing better required a considerable amount of non-obvious insight and some luck.




by Usman Latif  [Oct 11, 2006]