Tech & VC 11 Sep 2007 08:40 pm
Mobile Frustrations
I’ve spent a good amount of time in the last year at USV looking at consumer mobile applications, and I’d like to vent some frustrations.
The market’s too big to ignore: ~2.5 billion handsets floating out there. But the gatekeepers have an iron grip on all market entry points.
Pop quiz, hot shot: you’ve decided to build a mobile app, so you are faced with the following choice:
A) Build a rich app “on deck” working with the carriers. You have to choose a language for implementation (Flash lite? Brew? J2ME?). Whatever you choose, you’re going to limit the size of your market to only the phones that can run your app. Furthermore, by distributing through the carriers you could get lost with all the other “on deck” apps that come on the phone, which consumers never asked for (think: all the bloatware that comes on a Dell which never gets used). And, the carriers will attach a black hole to your expenses and kill your margin by charging the perfect price for “on deck” distribution: just enough to keep you alive, but never enough to let you grow outside their control.
B) Distribute a rich app “off deck.” You have the same operating system problem as before. Plus, the hurdles that users have to jump through to install your app are very high. You have to advertise online or find some other “off deck” means to publicize to your users that your app exists. Then, your users likely have to download and install your app by texting a shortcode or visiting a WAP site. And, then you probably have the standard site registration hurdles, expect its even harder than normal because a user doesn’t have a qwerty keyboard and has even less motivation to fill out a registration form than on a normal web app.
C) Build an SMS app so that anyone can use it without installing anything. You eliminate the problem of choosing an implementation language because texting is the lowest common denominator for cell phone functionality (besides making a call). But, your interaction is limited to clumps of 160 characters.
Aside from the *nix geeks reading this blog, I think most of us can agree its a good thing that we left the command-line interface (CLI) back in the 80s. Yet, SMS brings back all the pain of the CLI back with even less functionality than before. No hitting “tab” to auto-complete. No entries longer than 140 characters. No ASCII GUI hacks.
D) Build WAP site with server-side functionality only. It’s a richer interface than SMS and there are no hurdles to install like with richer apps. But, the level of interaction is pretty limited. No javascript means that every piece of functionality in your app requires a page refresh, which feels like a web1.0 app circa ‘99. And, it locks out most users who don’t have a data plan, so your market is limited.
E) …? Know a good option E? If so and you’re working on it, please shoot me an email at USV.
Excluding option E (and I’m sure there’s good possibilities I’m missing… that’s why I’ve been looking at this space for the past year), this quiz is tougher than any final exam I ever taken.
The best mobile services I’ve seen so far are services that are not mobile-only. They are services that use the strengths of the PC-based web (such as a big resolution screen and qwerty keyboard input) to handle the heavy lifting that cellphones suck at (like user registration). Then, they build a mobile interface to their site to enable smaller pieces of the service remotely. Facebook does this well. So does Twitter.
Yet, entrepreneurs are still chasing the concept of mobile-only apps. Techcrunch just featured a roundup of mobile-only social networking apps. And all mobile-only apps face the difficult decision I’ve outlined here.
I still see unbelievable promise in the mobile consumer apps sector. I can’t get over the possibility of 2.5 billion handset owners doing more than just talking on their devices. But, something in this environment needs to change to foster innovation. I don’t know if it’s a new startup carrier, an old stalwart carrier seeing the light, government intervention, or Google buying spectrum… but in the current environment I’m dismayed by the height of the hurdles to mobile startups and the bad choices they are force to make to clear them.
6 Responses to “Mobile Frustrations”

on 11 Sep 2007 at 10:35 pm 1.Nate Westheimer said …
Option E really is the iPhone solution.
The Safari-as-the-SDK deal really was a big deal because it opened this option E, which is having a rich internet application on your phone. More functionality than WAP but less ability for the carriers to interfere.
Of course the penetration of the iPhone is still very shallow, but I think that’s the direction things need to go in. Disempower those carriers with technology!
Here are my archives on the matter:
http://innonate.com/category/mobile/
on 12 Sep 2007 at 4:36 am 2.Harry S. said …
In my opinion, option E is to build an application for a group specific customers and to collect find some devices which have all the needed features or specifications. For your group of customers, you make a list of the supported devices and if there are new devices, you have to test, if your application runs to add it to the list.
I know, the topic was about the mass-market, my advice deals with a differentation-approach ;)
But i think it could be the E-option!
on 12 Sep 2007 at 7:11 am 3.Xenon said …
in 18months 80% of europes mobile devices will have a GPS-Receiver which enables especially all budget-owning marketing-spenders a whole new world of targeting customers (local based services).
After thereĀ“s money…systems will follow
on 12 Sep 2007 at 8:56 am 4.Andrew Parker said …
@Nate yea, I think this market with expand with iPod Touch, but it’s still a bit limited. I wonder if other phones will start rolling their own full Safari-like browsers (or pay Opera to do it for them).
@Harry That’s certainly an option, but it’s a gated approach that put you on a treadmill. I’m hoping to find a hockey stick growth chart in here somewhere, and I’m not sure this solution will get you there.
@Xenon GPS has been “coming” since I started using cell phones in the mid-90s. Can’t wait for it to arrive, but I’m not holding my breath. Where is GPS on the iPhone?
on 15 Sep 2007 at 1:40 pm 5.Nikolaj Nyholm said …
> (or pay Opera to do it for them).
Andrew,
The real opportunity is in with Opera (which I’ve been trying to tell them this for the past two years).
A few basic hooks from Opera Mini into the address book, calendar, sms, file system (ie. photos, videos, music, cache), camera, and bluetooth, coupled with a ‘mobile AJAX’ (akin to the widgets they have for Opera Mobile, but loadable on any page).
Being listed on the Oslo exchange, they hardly qualify for any VCs investment criteria but it’s definitely one of the big opportunities to leverage the 2.5 billion handset market.
/n
on 20 Sep 2007 at 11:33 am 6.Adam Riggs said …
I think you are making option B out to be much harder than it is. Assuming you are a somewhat decent developer (which you would have to be to have any success with any application) you would write your code in J2ME since it has the largest global market share.
Then you hook up with any number of vendors (Bango, iLoop etc.) that can help you with the distribution of your app to phones. They handle the carrier connectivity/billing and take a chunk of your revenue (granted its a big chunk, but hey its not easy stuff to do).
Sure then you have to market your application, but you’d have to do the same with an SMS app or a WAP site. If you use a website to market your app, people can find you through the web, register from their PC and the site can deliver the app over the air.
In the end it’s not that hard. It reaches a very large portion of the handsets and should your app be successful, porting the application from J2ME to BREW, while not trivial, can be done and there are people that will do it for you.