Apps are Dead. Long Live Experiences.

I like to get people’s attention by asserting “apps are dead”. I do this because it causes people to pause and think about what “apps” really are. After Apple started the app explosion in 2008 most apps were primarily client-side code. Today, however, it is almost impossible to find an app that does not rely on at least some Internet based service. In fact the apps most people use most of the time are almost all server-side code. The client-side code is there to project the experience on to one of many devices the user may have.

I also believe “apps are dead” because the end-user value proposition is no longer based on some piece of code a user buys in an app store on their device, but an entire experience they choose to use that spans all of their devices.  These experiences are powered by Internet (aka cloud) services. Examples of what I mean by experiences are Pandora, Kindle, Xbox LIVE, Netflix, Facebook, Gmail, and even The Walking Dead. All of these “apps” are available on all my devices and are curated over time.

Experiences are the new app.

Building great experiences requires the brand that is building them to be excellent at some core competency. For example, the people at American Idol need to be excellent at producing TV shows, identifying artists, managing Steven Tyler, and other things related to the entertainment industry. But to extend their experience beyond the TV (which they do) they also need to deliver excellent client-side code for a myriad of devices that connects to stable, secure, and scalable, Internet scale services.

In talking with brands and developers building these types of experiences three things are clear:

1. They want to focus on their core competencies.
2. Dealing with cross-platform mobile client development is their biggest challenge.
3. Building Internet scale services is their second biggest challenge.

I’ve written extensively on why I think solutions like Xamarin’s can really help ease the pain of cross-platform mobile development (and why I think HTML5 and WORA is a fallacy).

This post is focused on the third problem: The challenge of building Internet scale services.

In the past two years this trend away from “apps” has led to a bunch of new products intended to make it easier for brands, agencies, and developers to build  experiences. These new products range from Amazon’s AWS which provides what people call IaaS, or Infrastructure as a Service, to Heroku, which provides PaaS, or Platform as a Service. I see a place for all of these offerings (although there’s going to be some serious consolidation in the next few years given the number of these offerings that exist today).

The existing IaaS and PaaS offerings all make it easier for you, as a brand or developer, to write code that runs on the server.

I’m a huge fan of the newest type of “aaS” product, that is designed to enable you to power your experiences by not having to write ANY code on the server. These products are known as “BaaS” or Backend as a Service offerings. I’m a huge fan because my experience building the Windows Phone application platform, and engaging with all of the brands, publishers, and developers building apps made me realize the pain.

BaaS solutions are pain killers for brands and publishers and “It’s far easier to sell a pain killer than a vitamin.”

This is why I am an advisor and investor in one of the leading BaaS providers:  The Buddy Platform. 

Most BaaS providers provide low-level constructs in their service. I found the diagram below that illustrates the low-level kind of thinking these providers embody:

The Buddy Platform is unique amongst the BaaS providers in two primary ways:

1. Buddy provides a set of scenario based APIs.  Instead of just providing low-level primitives like collections and entities, Buddy also provides high-level constructs focused on the scenarios most mobile experiences need.
2. The scenario based approach enables Buddy to track API usage with high “semantic knowledge”. This enables Buddy to provide amazingly powerful real-time analytic information about the experience, and the users who use the experience.

Buddy’s APIs are built around the scenarios in this poster:

To illustrate the concept of “scenario-based” consider Pictures.  Instead of just providing a blob store with search and indexing, which is what other BaaS providers do, Buddy provides high-level constructs for photo albums and image filters. With Buddy, it is a trivial exercise to build an Instagram clone.

Another example is the Game API which, instead of just providing the developer with raw table/collections APIs, provides facilities for tracking players and scores. It includes player ranking semantics, boards, and supports tracking in-game state on a per-user basis.

Brands building experiences today are clueless about how and where users are using their apps. They would love to know how many mobile users are using the app in a coffee shop versus a bar, for example. They are hungry for the data, but building the back-end systems that collect it and synthesize it is out of their reach. Buddy’s scenario-based approach provides deep analytic information about a brand’s customers.

The Buddy Platform provides a complete back-end-as-a-service without writing a single line of server side code. Publishers get Internet scale performance and scalability without having to buy any servers. The scenario based APIs allow the service to provide the incredibly valuable analytic data that would require an entire team to build.

Today, Buddy launched a new component of the Buddy Platform: Commerce as a Service.

Everyone and their brother is trying to build in-app commerce solutions. In particular, doing in-app commerce in Facebook apps and games is huge right now (and a pain in the butt). Buddy’s new “Commerce as a Service” solution makes it ridiculously easy to build a Facebook app or game that supports purchasing things within the experience.

Publishers can now manage inventory outside of the app, and generate rich user insight via a robust analytics platform cross-referenced with purchase history. Using the Buddy Developer Portal the publisher manages a database of goods listings with prices and item metadata. “Store APIs” are provided to pull store inventory in real-time. These new APIs combine with the other Buddy APIs to optimize inventory, offer targeted promotions and cross reference purchase history against other information such as user demographics, social engagement, geo-location and other in-app activities.

An end-to-end user experience is a cohesive combination of devices, people, brands, channels, services, and content that improves over time.

For years people (BigCos, startups, investors, and users) have viewed the “app” as the center of the universe. And in the heyday of the Apple App Store this made sense.  But the proliferation of mobile platforms and the desire of brands to reach the largest number of customers means that, now days, this is flawed thinking. The new centerpiece of the consumer computing value proposition is the end-to-end user experience, and that user experience must be available on multiple platforms and is powered by cloud services.

IaaS, SaaS, and BaaS providers hold a unique, valuable, position in the industry right now. I’ve been extremely impressed with the Buddy team and their ability to build what I think is a unique pain killer for publishers and brands. They are on a roll with landing Nokia and regularly improving their offering with things like the new Commerce as a Service API.

Related posts:

• Experience = Stuff / Time
• Brand is a Critical Part of the End-to-End Experience
• Wanna Compete with Apple? Focus on Experiences
• Apps Must Be Cross Platform

What are your thoughts? Comment below.