Platforms vs Applications February 2019

Software is built in layers. Most of what we do stands on the shoulders of the work done by programmers that came before us. That applies to the actual computer the software runs on, as well as the lower level code that is required to translate the fancy modern languages people use to write software with the very basic level of interpreting instructions according to ones and zeros. All that stuff is basically the infrastructure of software, the main customer would be the developer who has to build software for a user on top of the infrastructure.

Above the infrastructure layer, there are approximately three more. The next three in order would be the platform, the applications and the services. Let’s unpack that.

A platform is something that enables applications. If you have an operating system, that’s technically a platform. The user of the operating system might be someone using a computer. The applications are the software that runs on the computer (Chrome, Microsoft Word, etc.). And the services would be the things that are necessary to learn about the application (could be support, documentation, or any other technical intelligence that the users need beyond code).

Tech companies have realized that the lower in that stack you are, the more valuable you can claim your software is. So service providers pretend to be applications (e.g. a service business that pretends they have a product), application providers pretend to be platforms (a good example would be an app for a particular OS or web platform – if it’s tied to an OS or another platform, it’s an application) and platform providers pretend to be infrastructure (because it sounds more impressive to say and because infrastructure has the biggest moat of all).

In practice however, the key comes down to who your customer is. The only purpose of a platform is to enable applications. The application could be a website where you can update the data in the platform, or another computer that updates the data on your behalf. Likewise, the customer of an application would be services: the value and understanding a user has to have in order to actually get value from the application. If you are infrastructure, everyone depends on you, but your customer is just the platform maker who decides what functionality to enable.

It’s similar to the way Thiel talks about monopolies in business, where non monopolies try to pretend they are monopolies when they talk to investors, where as monopolies try to pretend they are not monopolies to avoid regulatory crackdown. Platforms pretend that they can own all the applications themselves (sometimes it’s true, for example Google makes almost all the apps I use on my Android phone) where as applications tend to pretend they are a platform because then people won’t see the path to a competitor providing a better application experience.

There is nothing wrong with building something higher up the stack, it generally takes less time to get to market and has a more clear cause and effect relationship between the value being created and the value that can be captured through the process. But every ladder rung you rise in the software hierarchy means you are depending on another layer. I suspect that owning as many of the layers as you can results in providing the best or at least most unique experience for customers. This is the essence of vertical integration, which works well for manufacturing companies as well as technology companies it would seem. Google started with services, and worked backward through Android (platform) to fill in missing apps (literally, applications) and finally back to infrastructure (the servers and the phone hardware through the Pixel brand).

The main question when you’re starting a software company is where to begin. It seems like most either start doing services, and go down the stack, or start doing applications, and layer in services. Not too many seem to start as a platform, because it tends to require more funding and be less incremental. Platforms aren’t necessarily winner take all, so long as the applications you are enabling share similar data models, business logic and lower level infrastructure needs.

That’s really the key: the platform is the distance between bare metal computers and the thinking and acting required by the computer to meet the needs of an actual user. Finally, building applications is generally the only way to know what the platform really needs. People who dislike Windows tend to do so because they dislike aspects of Windows as a platform, generally they tend to like what that platform enables in terms of applications. Windows probably made the right call focusing on the application provider as customer, as opposed to users, but users seem to have shifted their preference towards the platforms that focus on them instead.

Mark Zuckerburg has a now leaked email in which he talks about how they are weak on mobile because Google and Apple both own their own full stack. Facebook only has applications and services, their platform isn’t really well suited for building mobile applications. So he talks about how in future, they need to make big bets on the platforms and applications that will win (such as VR), and that they have to build both the platform and the key applications. If cost is no object, but winning markets is important to your sustainability as a business, this is probably the right approach. It’s roughly the same one Google and Apple decided to take with mobile.

I found writing this up a good exercise in clarifying my own thinking. There are lots of good visualizations of this if you Google for software stack or platform vs. applications. Hopefully it’s helpful to those facing the same question.