Category Archives: Software Business

Announcing #twitstarter

Earlier today, I tweeted:

When I did, I didn’t look up #twitstarter, but now that I have, I think this might be the first serious usage of it. To be clear, #twitstarter is not the project I am asking you to back (more later).

To use #twitstarter, make a tweet with the hashtag #twitstarter, give a pledge amount, a goal, perks, how to pledge, and some indication of what the project is. That’s a lot to squish into 140 characters, but my tweet shows that it can be done.

#twitstarter FAQ

Q: Are you serious?
A: Yes — note the use of the #thisisserious hashtag, universally recognized as indicating seriousness. Despite what you might see, this is actually serious (details to follow)

Q: How do I enforce that the pledger will pay?
A: You can’t really — keep the amount low, and make a judgement call

Q: How do pledgers make payment?
A: I’m planning to use paypal or cash.

Q: Are you planning to do more work on #twitstarter
A: No

Q: Do you mind if I work on #twitstarter?
A: No — If you do, I hope you let me pledge a dollar to you

App.net is Bring Your Own Back-end (BYOBE) for mobile apps

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.

Can a content site be better with Ads?

I noticed that Horace Dediu, the founder and main author of asymco, recently started adding sponsored content to his site. Typically, his articles are data-backed analysis of the mobile market. To get a quick idea if you don’t know it, see this recent entry titled Revolutionary User Interfaces. In it, Horace uses data visualizations to show how Apple disrupted the phone market with multi-touch.

It happened despite having a clear, front row view of the transition of the industry from mobile voice to mobile computing. The shift in the basis of competition from “connecting people” to “connecting people to data” ended up being a classic disruptive trap. Many will argue that it was the failing of individual managers. Perhaps, but how did they conspire to fail simultaneously?

When you see disruption happening, it’s natural to seek out a cause, a pivotal magical “force” or event that enabled the weak to humble the strong–the proverbial sling that enabled David to defeat Goliath.

The article is worth reading, but what I wanted to point out was how his sponsored content is as interesting as a typical article. This one for Textastic reads almost as a follow-up.

With the new touch-based devices of today, we are seeing similar migrations of utilization to new jobs to be done. The simpler creative tasks migrate first and the advanced (or emergent) uses follow. Like with the microcomputer, the first common creative task for tablets happens to be text-based editing.

I have been giving a lot of thought to this kind of advertising, where it is as useful as the content to the reader. This is more than just relevance and unobtrusiveness, as I think advertising from The Deck accomplishes on sites like Daring Fireball. Instead, it turns advertising into something that I would read eagerly and perhaps miss if it were gone.