When I read this about Climber (a new iPhone app that lets you post short videos to App.net):
Our video pages simply rely on App.net post data to retrieve links to video files contained in personal App.net file storage. If a user chooses to delete their App.net post, or even just delete the video file in their file storage, then it can no longer be viewed on our website.
It struck me that the full cost of the back-end of this app was being paid for by the user. Until this, developers typically paid for a back-end or relied on free services.
When the developer paid, they had to deal with their app having a low, fixed life-time value, but unbounded costs. They either added a premium subscription service (Evernote), in-app currency (mostly games), or ads. Another common solution was to get acquihired before it imploded and have the new owner assume the costs (Instagram) or shut down the app (nearly everything else, but recently, Summly).
If they relied on free services, then they risked the service going away. Mobile RSS readers that treated Google Reader as a sync-service now have to either create their own or see what develops. Twitter client developers got hit with limited user-tokens.
App.net is offering another choice — Bring Your Own Back-end (BYOBE) — where they sell the user on the benefits of a backend and deliver less value to the developer (for a lower cost).
BYOBE isn’t new with App.net. Salesforce users have Apex, where they can find 3rd party apps that run on Salesforce servers. Apex app developers do not have to build out infrastructure for their applications if they can stay within Apex guidelines. In some sense, Evernote premium is also BYOBE for 3rd party applications. In fact, any app developer who solves their business model issue with a subscription service, can also transition to being a BYOBE provider. I’d put Github, Dropbox, and many others into this category.
But, App.net is nearly a pure-play BYOBE and is planning on something more general purpose than what we’ve seen. In the founding documents of App.net, Dalton Caldwell wrote:
As I understand, a hugely divisive internal debate occurred among Twitter employees around this time. One camp wanted to build the entire business around their realtime API. In this scenario, Twitter would have turned into something like a realtime cloud API company. […] I think back and wish the pro-API guys won that internal battle.
The price for developers is a flat $100/year. App.net gets its variable revenue from the app’s users as they must subscribe in order to use any app on top of the infrastructure. It’s tempting to think that they are paying for Alpha (their Twitter clone), but that’s just an app built on the infrastructure — they are paying for API usage, not Alpha.
App.net is not a paid service for mobile application developers — App.net is a paid service for mobile application users. The closest thing I can compare it to is iCloud, where users pay for iTunes Match or more storage, but developers get a syncing API to build on (or will eventually, when it works).
The benefits to users are clear (they are now paying, so they accrue some value)
- They control their data
- They aren’t sold to advertisers
- They can plan on some sort of longevity and consistency
Developers, who now have lower costs, also get less value.
- They give up control of the user and user data
- It would probably be harder to independently charge the user another subscription
They do get a service they can count on, but they could have that with Parse, Kinvey, AWS, or any number of paid back-end as a service companies. Most of the developer benefits are over free services, which I don’t think make sense to build on.
I certainly see why I’d want to be an App.net user based on this — but, since I don’t want Alpha (or message feed based services), it will make more sense when the app market is more diverse (not a bunch of Alpha clients).
As a developer, this model appeals to me because I think of this space more like a hobby — I would definitely forgo control to not have to think about or pay for the back-end. It would be even more interesting if App.net had a payments option or revenue share. Rather than Twitter’s limit of 100,000 user tokens, App.net is incented to reward a developer who gets that kind of traction. This brings costs to developers even lower (perhaps negative), and transfers value to themselves and users (they keep control of user payment data, and users have one bill).
I certainly don’t think this is the right mix of values/costs for every user — the key will be if the user thinks of themselves as having paid for an app and then get the services (and the other apps) along with it. Then, each different app category brings in different users. For example, it feels like Alpha costs $36/year, but what if you paid $36/year for your (let’s say) project management app, and just got Alpha for free? If Alpha is ever to have an enormous user-base (who all still pay for App.net), it has to be because they think they are paying for apps.
If there’s any kind of model for this, it’s the fact that I buy a data-plan for my phone and bring it to my apps. App developers do not have to sell me a data-plan. I buy electricity for my toaster, water for my shower, gas for my oven — consumers are no strangers to buying infrastructure.
Come to think of it — is this the natural order? The main alternative is turning out to be infrastructure subsidized by ads.