Clinkle speculation

I came across this article on Business Insider about the mysterious and mysteriously successful payment startup Clinkle. They haven’t announced publicly what their innovation is, but based on the promise of the app to replace cash and their¬†ambiguous¬†skeumorphic design, here is my guess at how Clinkle works. I believe it amounts to a decentralized social ATM.

Use Case

You, the Clinkle user, need to pay for something in meatspace, but you have only your phone and no cash or cards.

  1. You refer to your app to find a nearby Clinkle user, who is discovered via geolocation. 
  2. Through the app, you proposition that user for a trade: their cash or the use of their payment card in exchange for a transfer of funds from your Clinkle account to theirs. Presumably a fee is added to make the transaction worthwhile for the cash/card holder.
  3. The other Clinkle user either accepts or declines.

Playing with the idea

  • This creates the an opportunity to become a human ATM, an Automated Teller Man, potentially for substantial profit.
  • This can bestow double benefits on users with rewards credit cards.
  • This can be used to buy drugs. The transaction would go through as a cash transaction, but instead of handing over cash, the dealer would just hand over the goods. There’s some plausible deniability, but at some point I would think patterns would emerge.
  • This could be used for money laundering.
  • If Clinkle is to be trusted, this could be used to stay otherwise off the grid. I thought about this with Edward Snowden. In his flight, he would benefit greatly from having friends to make his transactions for him.
  • A business could choose to accept Clinkle directly for their services.
  • Alternatively the business could function as an ATM.
  • In order to accept payment directly, a business might be required to offer ATM services or debit-like cash back services where you would combine an ATM withdrawal with a purchase. That would help seed users. Also it would help businesses who get in a lot of cash and have to pay for armored cars to pick it up.
  • BitCoin tie-in?

A design question: should the additional (in)convenience fee be set or negotiable? A negotiable one would ensure that there’s always someone available for the transaction if you really need it. A fixed one would perhaps prevent the cashless person from feeling taken advantage of. Being able to advertise your own minimum/maximum rates might smooth things out. It’s really a chicken and egg problem. But ATMs set a reasonable anchor for the price so it would probably end up in that ballpark. I’m leaning heavily towards a market solution. People for whom large fees are worth while will encourage competition which will bring down prices. Also this is where some of that seed money could go. Clinkle could take care of or subsidize fees early on.

Potential big problem

This might lead to some people carrying around large amounts of cash. They would be vulnerable to be discovered through the app and robbed. The service could keep logs of user locations and transactions so that the robber would be traceable. I’m sure there’d be a way to work around this, though.


Mobile Site Desktop Launcher

Facebook used to have a lightweight version at that was designed to be used on desktops with 56kbps connection speeds. You can imagine that that was quite the narrow use case, so it’s no surprise that they discontinued it. But it was nice to have as it was much less cluttered than their regular homepage.

I found myself lamenting the loss of one day when I navigated to the mobile site on my desktop. I was just as fast. It would be a viable replacement if not for the fact that it stretched all content to the full width of the browser.

Today this idea coalesced and I realized that it might be nice to have a desktop homepage that consisted of multiple columns of mobile sites. It would be sort of like iGoogle, but better in a lot of ways.

I mocked this up with iframes and here’s the result.

Screenshot from 2013-06-06 13:51:31

iframes are not a great way to do this. I think the most proper way would be with Web Components, which were announced at the most recent Google I/O.

Contact me if you’re interested in this. As it is I just wanted a proof of concept. I don’t see this as something I would use myself.


Android vs. iOS usage

ReadWriteWeb has an article today trying to explain how iOS usage is so much higher than Android usage despite Android having a much larger install base. The article speculates but to me the reason is clear.

It’s because iDevices are more expensive. Only more dedicated users are willing to pay the premium. Marginal users are more likely to buy the cheaprer hardware. They’re the users for whom a $200 tablet is worth it but a $600 one is out of the question. They’re the users who are more likely to let that unsatisfying slow resistive touch-screened no-name device gather dust. If you drop half a grand on an iPad you don’t ignore it.

As for apps downloads and sales, Android, by its philosophy, tends to attract more technical users for whom it would be a personal failing to pay for something when they could get for free.

It’s like going to a prostitute. Why should I pay, when if I apply myself, maybe I could get it for free? -George Costanza, Seinfeld

Android users are the Georges of mobile users. Therefore they spend less on apps. Therefore developers that are chasing dollars develop for iOS.