It’s common for online applications to refer to themselves as a “platform” as soon as they have a public-facing API. Facebook is probably the biggest example of this, but it’s a fairly standard marketing tactic (I used to work for a company that did the same thing). Basically you make some public-facing endpoints, and voila, you’re now a “platform” – and developers please build stuff for us, so we can increase customer lock-in. That’s not how this actually, or ever, works – because that’s not how platforms work.
The fact is, having an API doesn’t automatically mean you’re a platform. Having an API simply means that other applications can interact with you. Even if you decide to make some of your “back-end API” endpoints public, you’re fundamentally still just making an application, albeit 1 people can interact with from their own code. Before calling yourself a platform, you might want to make sure your API covers the full set of your application’s functionality. Again, Facebook (and Twitter) are notoriously bad for having APIs but not let letting users actually have the full range of functionality that they have from the app itself. If the only way to take advantage of any of your product’s features is to log into the application itself, you’re not a platform.
Ben Thompson (of Stratechery fame) had probably the best definition of what makes a platform in the post “The Bill Gates Line,” specifically from the titular Bill Gates…line:
A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it.
It’s a good definition, I’d like to add a version that doesn’t rely on how other people are doing – you’ve built a platform when there’s nothing that can be done in your application that can’t also be done via your API. The whole point of platforms is for other applications to integrate with them exclusively via their API in order to build whole new products on top of them – that’s why we refer to them as platforms instead of simply services – with a platform, the API is the product.
Platforms solve a generalized problem for users well enough that they can use it to build something completely unrelated to that problem. That generalized problem needs to be both ubiquitous enough to have a broad user base, be difficult enough that it’s not worth companies building their own solutions in-house, and has enough variance that makes adding a separate abstraction layer really does add value to other companies. Platforms, unlike apps, are meant to be built on top of. That means from an accounting perspective they’re a pure cost without any revenue that can be directly attributed to them, but your business still depends on them.
Applications and services, on the other hand, need to be more “complete” products in and of themselves. They have to provide direct value (in a B2B context, quite literally) for their users. They may be intended to be something you use to help run your business, but because you can’t integrate as deeply and require people to eventually sign into the application itself, they need to be able claim that they’re making you money or doing something useful that you can’t do without. Applications take a “look what we do for you” approach, whereas platforms are more like “here’s something useful, what can you build with it?”
Another issue that I’m glossing over here is that of reliability. Downtime for an app or service is a problem, downtime for a platform means the business is barely able to operate, if it can operate at all. If you want to be a platform, you have to be up and running at all times. The quality of a platform is driven largely by it’s dependability, and if a platform develops any sort of reputation for going down, it’s unusable.
The use and marketing of an API creates the same problems for platforms that daily “stand-up” (does anyone on a distributed team actually stand up at these things?) status meetings create for Scrum – it’s such an iconic component that people assume that they can cargo cult it and say they’re “doing the thing.” The reality is that a) platforms aren’t very visible to their customers (which is a good thing), and b) while they don’t directly translate into value for their users, they’re still understood to be foundational to what you’re trying to do. If you want to build a platform, you need to go into it with a very different mindset than you would if you were building a more traditional app or service. You’re goal is to take something people would have to figure out from scratch, provide a solution to that problem people can plug into, do it reliably, and do it in a way that the only people who remember you’re there are the people who manage the integration with you. In other words, platforms are not a good vehicle to industry buzz, and the only way to translate building and running a platform into a massive market valuation is to be ubiquitous across virtually every industry, while only making a small piece of profit from any individual customer.
Look, there’s nothing wrong with creating a public API for your application or service and letting your customers use that as a way to integrate with your software. All I’m asking is to be honest about what you’re really offering because it helps users manage their expectations from your product. It’s also OK to decide you’re not going to build a platform after all – most software isn’t. The world ultimately runs on plain-old, consumer-facing apps after all. Find where you fit in the market, and how you can help your customers get the most out of what you’re offering. If that’s a web and/or mobile application, be an app. If it’s an app or service with a subset of functions exposed via API to let your customers build some automation around their workflows, that’s good too. But if you want to build the tools that other people can use to build their businesses, knowing full well that if you’re successful all of those other people will be making more from their products than you will from yours, then you’re ready to build a real platform.