Alex Pooley's Blog

Hello there, my name is Alex Pooley and I'm a freelance web developer residing in Perth, Western Australia. My passion is in the development of web sites that solve everyday problems. Here's a gallery of some of my notable work. If you need a web site designer or developer, contact me with further details. Lastly, you can read more about me.

Google Stomped On Kiko, Lessons For Startups

December 15th, 2006

Why don't you subscribe to my blog while you're here? I'm a freelance web developer and I blog about Ruby, Rails, and business online.

Go ahead and subscribe to my RSS feed. Thanks for visiting!


Google Stomped On Kiko

I’m flicking through Alexa right now and I came across Kiko’s Alexa traffic graph (included below). When I first saw the graph I noticed a sudden reversal in trend. The graph started going up very nicely, but then suddenly turned. I’ve highlighted the initial positive trend with the red support line. You can see the reversal occurring around the point where the traffic graph (in blue) crosses the red support line. I’ve shown the cross over area with the transparent pink box.

This cross over point appears to occur in April 2006. I did a quick search to see if I could find what happened during this date and I found something very interesting. Google’s Calendar service opened in April 2006! It’s then interesting to note that after about four months Kiko was for sale on eBay, which is why you see the spike. Kiko eventually sold on eBay to Tucows for $250,000. Tucows spoke with Mike Arrington from TechCrunch some time later and said they were going to white label the product and offer it to their retailer partners.

Further to this story, I found a post by Richard White who worked on the Kiko team who describes the reasons for the sale. Apparantly Kiko was sold because the team was burned out. More reasons are given throughout the post such as “adding too many features”, “30Boxes stole the calendar startup limelight”, and “no social networking component”. From my analysis I think that RIchard is incorrect. I think it’s an interesting example of how we look for reasons within our own experiences. From my own development experiences I know that I can spiral in to a mindset where I have to add “just one more feature” before I’m happy. The fact is that the market would be happy with a particular feature set, and that’s the feature set you have to provide, regardless of time constraints, internal conflicts, etc. Let me know if you know how to derive that feature set ;)

So what conclusions can be drawn from this? Stay out of Google’s path? Probably not a bad idea. From looking at the graph, Kiko were already in trouble with Google’s arrival, regardless of their internal issues. 30Boxes haven’t gone very far since they launched in February 2006, perhaps stunted by Google. But then look at services like Yedda the social answers site. Yedda are looking strong at a time when Google’s Answers service has just folded. I don’t want to pick on Richard, but it’s probably a good lesson for all of us (if you agree with my analysis of course), that an entrepreneur should always be mindful that they are there to please the market.

As an aside, I have a juicy analytical post on social networking effects coming up, so stay tuned!


There is some further analysis to Kiko’s demise here if you’re interested in following up:

ScribbleHere Redesign

December 2nd, 2006

The ScribbleHere chat interface has been redesigned so that it’s more simple, obvious, and less taxing on the back end.

My biggest problem with the previous design was that I was using a context menu. Context menu’s are common place on the desktop, but very uncommon on web sites. This made a lot of important functionality hidden behind an unintuitive interface.

As for the back end - the previous interface pulled in all posts from chat pages that the user owned, or was a member of. The problem with this is that every request is then a very specific request for data tailored for each user, so no two users make the same query. With the new interface, queries are made on a per page basis, so there is only a single request actually processed for each user on the page. The other users will receive a cached copy. By caching the performance improves by greater than a magnitude.

The down side of the change is that you can’t tell if there is activity on other chat pages unless you have them open. However, you can easily navigate to any of your page and leave multiple chats open if you like.

Last thing of note, I added a bunch of subscription buttons to the chat interface so you can now passively monitor your chats by subscribing to them in your feed reader.

ScribbleHere

buy mp3 music uk vpn