Steve Kaliski

Platform Exploration

In a world with so many disconnected tools, there’s a battle to become the center of the workflow. And how’re companies approaching this?

Platform. Platform. Platform1. It’s a word we hear over and over again, and has become a default word used in most pitch decks for fledging startups. The classic definition is:

“A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform.” - Bill Gates

Of particular interest to me is the “developer platform.” A set of APIs, SDKs, and tools that enable a developer to build something.

Traditionally, many “developer platforms” looked quite similar, and have essentially existed in two chapters2. The first is composed of OAuth2.0 and an HTTP API, a mechanism for authenticating a user and getting information about them. Think Facebook Login. The second is composed of webhooks, notifying me and my service when activity occurs in the platform. Think CircleCI.

In both cases, the user experience has been off platform. The end user likely accesses this information in a different app or on a different domain. It’s extending the context and information of that software (social network, software tool, etc) into a separate utility, such as bringing in my list of friends, running tests when a new commit is pushed to a code repository, etc.

The third chapter is the emergence of the plugin3. There are other terms for it, think installable app or extension, but the critical difference is the developer is building an in platform experience, where the experience looks native. It’s as though the creators of the platform built the feature themselves.

Slack. GitHub. Figma. Zeit. These SaaS companies have all taken a swing at it, and have done so in their own unique ways. Whereas OAuth2.0, HTTP APIs, and webhooks have well understood and commonly accepted standards, plugins do not.

While the implementation is different, they all share a common goal. Pulling from the aforementioned services, they all do something to: “extend,” “automate,” and improve “workflow.” And most critically, right within their tool.

In my time as an engineer I’ve been both the builder of the plugin and the platform itself. With that perspective, I think it’ll be interesting to evaluate how different software companies approach the development and deployment of plugins. In subsequent posts I’ll be picking one of these tools and document my process of building a plugin.

If you want to follow along, checkout my twitter!


  1. It’s the SaaS company version of “Location. Location. Location.”

  2. There’s a lot more nuance to this. I’ve chosed to ignore app marketplaces. Facebook has experimented with in-app games in the past.

  3. Again, some nuance. Chrome extensions have been around since 2009.


Steve Kaliski

Hey! I am Steve Kaliski, an engineer and entreprenuer based in NYC. I love building tools to help people do their jobs.