Brightkite rushes to get it right, unlike some others

With every third “new” native app crashing on my phone after a few minutes of use now that I’ve upgraded from 1.1.4 to 2.0, I’m not in a huge rush to jump from the web apps that I like and use to native ones.

Doing it right doesn’t mean rushing to the market place

I don’t honestly know why folks have been a bit anxious that Brightkite hasn’t yet released a native iPhone app. Maybe it’s like when the holiday season rolls around and you’re the only Jewish kid on the block… you see all of the other kids get a ton of stuff at once, and you have to wait through a day of sweaters, boxes of pencils and other gifts that don’t stimulate your holiday fantasies until you get that Red Ryder BB Gun you’ve been pining for. And what happens when another kid gets it before you do? They shoot some other kid’s eye out… totally blowing your chances at getting one for yourself.

Yes there are quite a few other location-based networks out there, but most of them focus on a typical social-networking model (or twitter) and add location like it’s salad dressing on iceburg lettuce. To me, Brightkite just tastes like a whole different kind of salad.

It seems like most people just don’t want to have to type in the address of where they are, and since FireEagle’s API allow’s digestion of data much easier than sharing it’s data with other services, there hasn’t really been an automated way to geolocate these services from raw geodata to a physical address. One thing I did as soon as I started using Brightkite to make mobile checkins easier, is to create a placemark of addresses or businesses I visit frequently, so when I just type in the name of the placemark, everything comes up in a jiffy.

Here’s a short explanation as to why they didn’t have an app ready to roar on the 10th (or 11th) of this month:

1. We don’t have a 3G iPhone to test on yet. More specifically, we’d like to see how well the GPS in the new phones works.
2. We don’t want to release something that’s not rock-solid. And by rock-solid, we don’t mean crashing, but rock-solid from a usability standpoint. The app should be as easy to use as possible. We have some very ambitious goals concerning the user interface, but getting it just right takes time and we’re just not quite there yet.

Not having a copy of the device you’re developing for is a great reason to hold off releasing software. But what’s special here is their second point… They are really stressing usability, they care about not only if the software is going to function, but really how each user is going to interact with it’s interface.

In the meantime they thought they’d release their API and add a new feature to keep people (and developers) happy.

So who’s maybe jumped the gun here?

Everyone’s favorite giant corporation! This is a great example of a native app that I’ve installed, then abandoned for the web app is Facebook’s… The other day Facebook released an update to their already released native app for the iPhone, and though people seem really happy with the update, I’ve honestly failed to notice any significant changes (though they must be there…. somewhere) and have gone back to using their web app over at iphone.facebook.com since it allows me to respond to friend and even requests unlike the native app. Though the UI of the native app is relatively snappy, it doesn’t have nearly all of the functionality of their existing web app, it still requires full connectivity to use, and isn’t much more that a bookmark to a dumbed-down version of their previous offering.

So is it worth it to go native?

John Allsop also just wrote a long and interesting piece comparing native apps to webapps over at web directions south. Though he didn’t really look into anything but the free apps, the article does have some good points, especially regarding how to monetize your efforts (as a developer or company), and what it really takes to make a couple of bucks off your hard work.

Let’s say you sell your App for $1.95. You’ll need to sell 25,000 copies to make $50KUSD. Hang on, Apple takes about 30% so you’ll need to sell 30% more. That’s 36,500 copies. If you look at a typical conversion rate of say 3% of downloads to sales (in my experience, good Mac apps can get that kind of conversion), if this were a desktop shareware app, you’d need to have 1.2 million downloads. That’s more than 10% of the entire projected iPhone user base for the end of 2008 interested in your app.

OK, let’s think about higher price points - at $5, you need to sell 14,000 copies to make $50KUSD, with a theoretical download of 476,000 demo copies. Up this to $10, and we are looking at 7,000 sales, and 233,000 demo downloads. And that’s for a single developer. Double this for 2 developers, triple it for a team of three, and so on.

Now, let’s compare the “sell the app” business model with the increasingly common “subscribing to a service” model. Let’s say we only have customers paying $5 a month. They are already paying $60 a year! So to make our $50KUSD, we’ll need around 1000 customers (about 14% of the number of sales of a $10 app). And I’ve factored in about 12% costs here (transaction and hosting costs, based on personal experience).