Be Either an App or a Platform, Not Both

If you think the thing you are building is both an “app” and a “platform” you will fail. Oh, and if you think it’s going to be a just a platform, you will fail too.

(Update: April 6, 2012 – I updated this post with some typo fixes and minor tweaks).

A recent story on Hacker News gave me an excuse to write down my thoughts on this subject. I’m reposting here in order to elaborate a bit more.

The story I’m referring to was on Your startup probably isn’t a platform.  In it, the author says a few things I happen to agree with, such as:

Simply having an API doesn’t make your company a platform. Similarly, simply having a piece of software that gets embedded in other products doesn’t make your company a platform; that just means your product is usefully extensible or perhaps your a dev tools business.

I have two points to make on this subject:

  1. A startup building a product or service that tries to be both an “app” anda “platform” will fail.
  2. There are very few (if any) examples of successful platforms that started as a platform.

Point #1 – Be an app. Or a platform. But not both!

In my experience, when building a new software based product, teams need to make a choice very early on whether they are building something that is all about end-user value (“an app”) or all about 3rd party value (“a platform”).

Endeavors that attempt to do both lack focus. They don’t do a great job building a great user experience and they don’t do a great job enabling 3rd parties because these two things are in tension. Example: enabling a 3rd party plug-in model requires the creation of UI that is often complex from a user’s perspective. The investment in that UI to make it great (especially at an early stage when you don’t really know what or how many 3rd party extensions will get built) could be better spent on building great end-user-valuable functionality in the core of the product.

You have a limited number of resources that can work on any endeavor. Call it headcount. People who are excellent at creating user experiences, working with design, and polishing pixels are almost never excellent at building easy to use, scalable, and flexible APIs. And of course the reverse is even more true: plumbers can’t paint worth beans. If you choose to be both an app and a platform you will have half the great plumbers and half the great painters you’d have otherwise.

Building something new implies we really don’t know what we’re doing. If we did, it wouldn’t be new. For the engineering of this new thing, we’re going to start with a plan and then dive in and start building. As soon as that thing we’re building gets exposed to a customer we all know that the plan goes out the window.

“No plan of battle ever survives contact with the enemy” – Heinz Guderian

Once that plan is out the window we need to iterate/pivot/refine. Quickly. Both user experience and APIs are difficult to change once coded (APIs are harder).  Changing both simultaneously will kill you. Been there. Done that. Got the T-shirt.

This point is all about focus. To be successful startups need extreme focus and choosing to do two things that are in such obvious tension with each other is a recipe for disaster.

Point #2: Don’t be a platform!

Go ahead. Name a few successful “platforms”.

Before you do, for the sake of argument, agree with me that “successful platform” implies the platform has a vibrant set of independent partners who both contribute to and “profit” from the platform. I could also use the term “virtuous platform” which has come to mean a platform composed of a multi-sided market where each side of the market derives value in a symbiotic or virtuous cycle with the others.

The “virtuous platform cycle” that most people use as the prototypical example is the Windows ecosystem. The market sides were: Windows, Intel, OEMs (e.g. Compaq, DELL), IHVs (e.g. ATI, SoundBlaster), ISVs (e.g. Lotus, Adobe, Office), retailers & channel (e.g. Egghead), and of course, end users.

All of these “market sides” drew great value from one another as part of the Windows ecosystem. They all made money, hand-over-foot, because the “virtuous platform cycle” snowballed.

There are many examples of other platforms with a virtuous cycle today. Google’s search engine,, Apple’s iOS, and on a smaller scale something like Minecraft (although that’s a nascent example).

For each example YOU come up with, ask this question: What came first, “end user value” or “developer/3rd party platform”? I struggle to find examples where the platform STARTED as something that was entirely focused on developer/3rd party value. You might argue Java, but then I’d say “in what way did the creator of that platform make any money off the platform?”.

With very, very few exceptions, the existing “platforms” we all know and love started out being primarily about end-user value. Extensibility, APIs, plug-ins, and embed-ability all became important later in the life-cycle.

I turns out the best way to build a platform is to build something that end-users love and add “platform” later. So do that.

Don’t walk away from this with the idea that you can’t do a little platformy stuff as you build your “app”.  If you believe extensibility, APIs, plug-ins, and embed-ability are something you want in the future, or if you have a very specific extensibility feature then do it. But do it as a feature. Something that you can cut.

Here’s a personal example.  When we built Windows Home Server we explicitly choose to “be an app”.  Delivering on our core end user value proposition was the highest priority.  But our OEM partners really wanted some extensibility so they could differentiate.  So we added to our list of features a simple plug-in model that would allow those partners to have a little bit of configuration UI hosted within the Home Server Console. It was treated as one feature among dozens and was prioritized in such a way that if, push came to shove, we could cut it in order to ship.

“Shipping is a feature too” – A lot of great engineering leaders

Only a small part of the team worked on it for a time-boxed amount of time. Nobody on the team was confused: We were an app, not a platform.

Developer Tools Are Not Platforms

I get a a lot of people asking if something like .NET, Java, Ruby on Rails, or Node.js are examples of platforms that were created standalone. They are not. Because they are not platforms. They are developer tools. In my mind, a developer tool is an app for the developer customer.

This post is about focus. Here are some other posts I’ve written on how to build ventures that are focused:

© Charlie Kindel. All Rights Reserved.


Comment on this post

This site uses Akismet to reduce spam. Learn how your comment data is processed.