Thread by @stevesi

Transforming from app/service to platform often (not always) involves adding extensibility (API) for other companies or customers to use. Using extensibility aside from solving a missing capability, is sticky and good for biz. Some patterns, traps, pitfalls & lessons 1/

2/ Most SaaS can be thought of as "mostly about data", "mostly about experience", or "mostly about an API", especially early. Over time most apps will naturally expand to be more of what it isn't, normal. To speed expansion and feature coverage, extensibility to the rescue.

3/ An app that is mostly about storing data will often expand to both ingest more data but to also display/report/synthesize data. Early on exposing an API that allows more data to be ingested or allows other tools to serve as front ends is natural.

4/ App that is mostly UX will often expand by including data sources from other apps (no matter how other apps fit in the spectrum)—commonly called integrations. Most UX-centric apps aim to envelope other apps, viewing those apps as "data" to be consumed within their experience.

5/ API "apps" will naturally expand in either direction—they might start storing data as a system of record of some kind (often customers will start using it that way) or they will gradually add more UX to support the API (often reporting and analysis) to become an app-like tool.

6/ The challenge in these cases is always about identifying the third party developers willing to invest in building capabilities on top of some extensibility layer that may or may not run straight into the very place an app is already expanding. AND…

7/ Most all of the time, every app that customers want integrated is itself executing from the same playbook of expanding capability by adding features (that are what you do) or by adding APIs (that they want you to take advantage of).

8/ So the common pattern of offering an API/extensibility that is advantageous to your App often finds little traction because other Apps do not naturally do things that are advantageous for somoene else. They do work in their own best interests.

9/ For example, an App that views itself as a data aggregator has little motivation to offer an API to make it east to treat it like a data source but a bit motivation to treat everyone else like a data source.

10/ A UX centric app naturally wants to be the experience for everything and won't "get out of the way" for an App that wants to treat it like a source of data. Conversely any App with a UX isn't likely to "integrate" ceding the UX they care so much about to an integration.

11/ What this means at a practical level is that extensibility/customization, if the intent is to be strategic for both your App and the developer, is that it must start from a point of view that is a winning proposition for the developer on the merits.

12/ It might even be that the extensibility on paper works against your goals—you might give up UX branding or your own UX flow, or you might support data being extracted.

13/ In general, extensiblity assuming your App is the center of everything are very difficult to get traction. Even w/ early adopters, they will soon bump up against ] restrictions/limits and get frustrated. It's hard to build whole product inside another or w/o your own data.

14/ There are many specific "exceptions" to this broad challenge. For example, narrowly defined plugin architectures (eg Photoshop, conversion utilities, visual effects, etc.)

15/ Over time, a pattern that emerges is extensibilty of this "weak form" that is tough to build a whole product out of, tends to become a spring board for non-integrated products (built w/o your App) or a service business around your App.

16/ But the strongest products that aim for becoming a platform take one of two approaches. 1) By and large they become the UX that defines a whole role or job within a company. Extensibility is opportunistic and often used in point solutions.

17/ or 2) Apps allow major "plugability" or "deep integration" that they themselves can use. They allow complete replacement of UX so as to attract broad use of the underlying data while a Developer maintains their own experience or…

18/ They allow their data to be used as though it was a developer's own data. The test for this is being able to build your own UX on top of your extensibility API to your own data.

19/ But "build it and they will come" usually has some short term pop followed by slog. So make the choice to really welcome developers to your platform and give them the capability thet want, if you're going to engage 3rd party developer community.

20/ Developers really want CUSTOMERS and CONTROL. Building for your platform should bring real paying customers to the Dev. Devs also want to be in control of the end-to-end experience of those customers.

21/ The toughest thing to internalize is that developers are not looking to help your app to fill in holes or to improve it. There are some who will gladly "help out" but they are looking to make their usage better, not to build a business which is what you really want.

22/ Developers, developers, developers is about the developers and what benefits they accrue, not about the direct benefits your App gets.

PS/ Lots of tips and ideas in this substack. ty @CeciStalls calyx.substack.com