Strong Opinions @marksbirch

When you are building the next great Internet innovation, where you build can make all the difference between success and failure.  Like the real estate adage about location, API’s and platforms can be hugely important in gaining traction.  But platforms can also be dangerous propositions and reading Bijan’s post about “getting Sherlocked” brings to light the risks involved in choosing your ecosystem:

The story became known to developers as “Getting Sherlocked”. Third parties getting trounced by the big platform. Building interesting desktop apps for MacOS or Windows always came with the getting sherlocked risk.

The desktop world is rife with examples of groundbreaking applications getting crushed by the platform.  Now we are seeing it happen with more frequency in the web world.  Twitter made headlines recently by putting the kibosh on LinkedIn’s tweet syndication deal.  Barely a year went by when they gave Twitter clients the guillotine.  LinkedIn however is no innocent victim, declaring an open API while making it impossible to leverage.   And who can forget the infamous 2011 messaging app massacre when Apple integrated messaging into iOS.  You live by the platform and you die by the platform.

Open API’s and platforms are as open as it is convenient for the provider.  Unless it is a completely open source project, commercial issues and political concerns will always hold sway over the desires of the application and developer ecosystem.  Twitter wants full control of the user experience (and thus ad impressions).  LinkedIn sees profile data and resume information as proprietary.  Apple, Google, Microsoft, Oracle, Facebook and every other commercial vendor have responsibilities that often conflict with their ecosystem, especially when it comes to monetization and competitive positioning.

Platforms are great launching pads.  Being able to leverage existing data sources to add value to your own application or web service is an excellent way to accelerate growth, build user loyalty, and enhance credibility.  Blindly putting all your marbles into one platform however is simply poor planning and potentially setting yourself up for failure.

Think about the way the railroads were built and the communities that thrived or died in this ecosystem:

• Build on the tracks – This is where you are building something which is a component integral (or potentially integral) to the platform.   Building a client to view and respond to tweets is one such application.  While many of these apps where arguable superior to Twitter’s own client, they were sitting ducks when the Twitter express came barreling down the tracks.  Analogous to the Karelia story when Apple did the same thing, when you are on the tracks, be prepared to get your railcar rocked.
• Build off the station – While not quite independent, these products have a broader purpose and value proposition.  A good example of these apps would be social media analysis tools.  They depend on streaming feeds from social networking sites like Facebook and Twitter, but they are not wholly dependent on one particular channel to develop business and gain customers.  If the trains traffic suddenly ends or bypasses the station, at least these apps have a chance to survive or pivot to something else.
• Build away from town – These solutions connect to platforms and can utilize the access to the platform in order to generate value, however they are wholly self-reliant and potential platforms in their own right.  Along the intercontinental railroad, many towns rose quickly, but many of those towns eventually died a slow and excruciating death when the trains stopped coming.  However, where businesses flourished with sustainable revenues streams, an independent economy rose beyond merely being another throwaway pitstop on a rail line.

Obviously, the best situation is to be the latter kind of startup, creating value independent of any one or two particular platforms.  There is significantly less risk in the tie-up and falling prey to the whims of the platform.  The challenge however is to balance independence with the benefits derived from leveraging a platform.  What you do not want to be is an island, killing yourself to develop something that is about as empty as a graveyard at night and as desperate as supermarket sushi.

How do you strive to maintain a healthy balance between independence and the benefits of a platform?  Start by building something that is more than merely an add-on or feature.  Ask yourself if what you are building could easily be implemented by the platform provider in short order or cut-off due to commercial considerations.  Aim to build on the platform initially to generate usage and gain users, but plan on implementing your broader vision quickly.  Build your technology in such a way that you can quickly use another service or simply turn off the feature altogether.  Having an API intermediary layer like YourTrove or Singly could easy some of the technical burden.  Take control of the customer experience by capturing the core user data and maintaining contact with users on a regular basis.  When it is time to jump off the platform, you do not lose the relationship with users (and the user data) in the process.  Lastly, do not be surprised if the plug is pulled all of a sudden.  If you read the terms and conditions of all these providers, they have extraordinary leeway to bounce whomever they want whenever they want.

If you had to sum up this advice in a nutshell, it would be do not strive to be the pit stop, instead be the destination.  Of course, you are more than welcome to build your feature or add-on product, just do not expect to have a lasting business or attract much interest from investors.  Being the destination on the other hand may be the harder road initially, but eventually it pays off many times over in the end.