Managing Platform Risk


Managing Platform Risk

As I'm building Playlist Kit, I'm starting to think about the risk of building on Spotify. I have built on other platforms, like Twitter, before and found this can be a risky affair.

What are the risks?

There are a few kinds of platform risk…

The main risk that people talk about is the risk of being shutdown by the very platform you’re building on. They could simply shut down the access to their platform, they currently offer you, and you should. Your application would no longer work and your users/customers would not be able to use your application.

This has happened on a number of cases with platforms like Twitter. API keys being used to build 3rd party clients were disabled, some with tens of thousands of users suddenly stopped working.

Another type of risk, is that the platform builds the features you built directly into their platform. What users came to use for (even paid you for) is now available directly. Apple had done this a number of times.

Utilities such as f.lux gave the ability to adjust their monitor brightness during the day, until Apple included the "Night Shift" feature into macOS, they even banned the Flux app from their App Store. Apple also "copied" all the search features from a utility called Watson into their Sherlock application.

Finally, a little harder to quantify, but unless you have an exclusive relationship with the platform, there is nothing stopping anyone else building the same/similar app on top of the platform. They will have the same access to the platform that you do, building a moat around your application becomes very difficult.

Why take the risk?

There are a couple of different reasons that despite these risks, it can still be beneficial to build on these platforms.

Without access to the Spotify platform, I'd have a lot more to build, and for a small solo maker that would put things out of reach.

While I may be able to access a database of artists, and their music catalog, how would people listen to the generated playlists?

Just generating a list might work for a few people, but the ability to push the list directly into a player make it much more likely users will use Playlist Kit. While may be able to build a player myself, I would not be able to license all the music to allow people to listen?

Platforms can give you access to their entire user base, especially those that have marketplaces that list all the applications available on those platforms. This can mean users find you rather than you having to find users.

Even on a platform like Twitter, originally each post would share the client that was used to make that post. This gave an easy way to grow use of your client on the platform.

Some platforms (such as Shopify) also handle the billing side of your application. This makes it easier to onboard new users as they already have their billing details stored in Shopify.

All in, while there is risk, there can also be many benefits for building on other platforms.

Can you mitigate the risks?

Depending on what you're building, there might be ways to mitigate the platform risk. Could I interface with Apple Music, instead of just Spotify, to help spread the risk across multiple platforms?

If you're building a social media client, could you support Threads, Bluesky, LinkedIn as well as Twitter?

It's not always possible, and not always possible to foresee. Platforms won't build your features into their platforms unless they are popular, so you can't see the full risk, and you execute, and execute well.

There is also always the possibility that the platform will want to acquire your application if it does a good job for its users, a definite upside to building on others platforms.

I'm working on pushing Playlist Kit to production servers, so hopefully my next post will share details of my Spotify application submission.

Cheers,
Mubs

Sideproject MVP

Subscribe for tips and tricks for building your side project, from someone who's built over 100.

Read more from Sideproject MVP

Mubs A recent tweet by Pieter Levels reminded me of the importance of being a jack of all trades when working on side projects. It's not enough to be able to good build software, there is a lot more to building a good project than the quality of the software, in fact that's probably pretty low on the list. Wrote my thoughts on being a jack of all trades:Mastering the Art of Being a Jack of All Trades Continuing my learning for SEO skills, I recently completed a build challenge run by the team...

Mubs With over 120 side projects, a question I often get is: "How do ship so much?" Keeping on track with projects can be difficult when after the demands of a day job and personal commitments. I've shared some of the ways I stay on track with my projects in the most recent blog post: How to keep shipping? I'm focusing on SEO as a way to market (and grow) projects this year, and was excited to see that Danny Postma will be publishing a course on SEO soon. I've already learned a lot from...

Mubs This week, I've been thinking about who I'm building for. Yes, I'm building a side project for my own reasons (networking, revenue, whatever) but who is the actual project for? What is the Ideal Customer Profile for your project, and why is it helpful to think about that right when you get started. I dig a little deeper into the concept, and how I worked through the process for a previous project: Defining your ICP Featured Side Project I wanted to take a minute to highlight a side...