"Excuse Me" APIs: Why most Facebook apps disappoint

Alright...  most of 'em just downright suck.  But why?  Is the Facebook platform not all it is cracked up to be?

Many people are giving the excuse that the really robust versions of our favorite web apps just haven't had time to get built, but doesn't that violate everything we learned in BizDev 2.0?  If every time you need to syndicate your service to another place, you need to rebuild, your infrastructure is not optimized for a world of small pieces loosely joined, aggregated, remixed, mashed up, etc.  Aren't all these applications supposed to be able to live and function anywhere?

There are two main reasons why the current group of Facebook apps have been generally unappealing:

1) Like many websites, many of them were not meant to be any more than amusing wastes of time.  We went from catblogging to sheep tossing, which is fine. 
2) Many web services develop their own APIs as an afterthought--a narrow bottleneck through which Facebook users are struggling to squeeze utility, since most of the FB apps use the original app's API.

For applications that are essentially powered by data (i.e. Most of Web 2.0), you essentially have a database, input mechanisms and output - a way to call, manipulate and present the data.  Ideally, they're built in such a way that they're largely agnostic as to where the input and the output occurs.  Even the business models should be such so that any user, any piece of data, anything can be monetized or contribute to monetization even if it occurs off of your main site.

In fact, the very idea of "conversions" should have no meaning here.  You shouldn't be trying to pull users off Facebook... you should be shoving the full functionality and business model of your app IN Facebook.   If your Facebook app has no business model, then your service has no business model.  If you're building a service and designing it in such a way that the ultimate goal is land at your destination, that kind of territoriality is going to be a major stumbling block with partners.

Take Voki, for example.  The Voki avatars are powered by the Oddcast avatar engine and audio database--neither of which actually live at Voki.com.  They live on some wacky internal Oddcast domain and unless we wanted to clone that engine and database, which we didn't, Voki.com had to be built in such a way that it actually used our own APIs.  So, the site is essentially the first partner implementation of itself.  The core features of Voki.com--launching an editor, saving an avatar creation to a database, publishing it to a page, calling previously made scenes--are all fully functional within our API.  Therefore, you could recreate an implementation of Voki just about anywhere you wanted--which is essentially what we did on Facebook.   There's a link to create your avatar, a button thta publishes it back to our system, and ways to call previous scenes.  We rely on the Facebook side of the API to distribute those scenes to the Newsfeed, specific friends or your profile. 

Actually, one could argue that the Voki app that is on Facebook is better and more useful than the one on Voki.com.  That was our idea for the partner program--that partners bring with them a context and a purpose unique to that environment.  Voki in an instant messenger chat box would be more compelling than the Voki on Voki.com and so would Voki on event invitations, fantasy sports bulletin boards, etc. 

Your destination site should actually be the least compelling implementation of your product, because it has to serve mass appeal and has no context for participation and use. 

Developers and entrepreneurs need to stop thinking about Facebook as s different way to build or even a different place to build.. its a partnership deal plain and simple... and your app needs to be easily "partnerable" without a ton of custom work.  Databases need to flow across your platform and users should be able to encounter it at multiple touch points, but it shouldn't require a major rebuild.