What your app store says about you
If you’ve looked around the SaaS landscape in the last decade or so, you might have noticed something — everyone’s trying to build a software marketplace. It seems like an inevitable prescription for a software company as they cast about for yet more creative ways to grow forever. For product-curious engineers, this phenomenon deserves closer examination, because, in addition to growing revenue, these marketplaces can teach us how these companies think about the strategy behind their products.
What's a software marketplace?
Software marketplaces are two-sided systems built into existing software products that connect third party developers to that product's users. The company hosting the marketplace exposes some APIs for third party developers to integrate with and provides a way for them to share the new functionality they produce. The details vary — some marketplaces are called “app stores” or “app directories”, and the offerings can be called “apps”, “plugins”, “power-ups”, or “add-ons”. But whether it’s Apple’s App Store, Salesforce’s AppExchange, or Wordpress’s Plugins ecosystem, the concept is the same.
Marketplaces incentivize third-party developers in different ways. Some give developers a cut of the SaaS revenue, others let them charge a flat fee, and some even choose to let the third-party developers figure out monetization for themselves. Regardless, the core concept is that developers outside the company are going to help the company build the product.
This decision turns the original product into a platform. Third-party developers contribute new functionality to the platform, and the platform’s users get to customize their experiences by shopping on the marketplace. Crucially, becoming a platform increases the parties in the relationship from two — the company and its users - to three: the company, its users, and its third party developers.
Why are marketplaces so common?
If done properly, building software marketplaces into existing products benefits everyone involved. A healthy marketplace improves the user experience, incentivizes third-party developer participation, and furthers central product goals.
Why are they good for users?
Software marketplaces are good for users for the same reasons that Amazon and grocery stores are popular - they offer users convenience and choice. Within a given product, marketplaces let users pick and choose which individual features they want to use and pay for, letting them tailor the product to their specific needs.
There are often lots of highly specialized options available for users to choose from on software marketplaces, because there can be many more third-party developers than platform company developers. Also, the design and infrastructure of the marketplace typically reduces the effort necessary for those developers to contribute features within the existing product. These two factors combine to produce a wide variety of niche marketplace offerings which fill user needs better than the platform company could afford to on its own.
Why do developers contribute to them?
Marketplaces often include facilities for developers to monetize their contributions directly, but getting a cut of the revenue that the platform company collects is not the only way that third-party developers can get paid. Many marketplace participants are actually other large companies - Google offers apps for its products on the Apple App store, for example. These third-party developers participate in other companies’ marketplaces to offer integrations with their own products, which increases the value of those products even without monetizing their marketplace offerings.
The infrastructure built into a marketplace and the reach offered by the platform company also incentivizes smaller companies and independent developers to contribute to the marketplace. By building for the marketplace, these developers can tap into the platform’s already-monetized user base instead of working to build an audience for themselves. Software marketplace architecture often includes hosting, a build-and-deploy toolkit, and a plugin framework for developers to start with. The opportunity to monetize, the built-in audience, and developer tools help third-party developers shorten their time to market in comparison to striking out on their own.
Why do companies build them into their products?
Software marketplaces let the platform company avoid costly user research and engineering. Instead of doing this itself, the platform company can rely on third-party developers to do it for them. This replaces their expensive in-house efforts with what is, from the platform’s perspective, automatic adaptation, driven and regulated by supply and demand within the captive marketplace.
Marketplaces also provide a way for the platform company to serve a long tail of user needs without the associated engineering cost. It can be very costly and time consuming to comb through an existing product and add all the bells and whistles to fill every feature request from your users. From the perspective of the company’s software engineers, if your business requires this type of work, you will likely implement an internal plugin interface anyway. In that case, exposing it for external consumption offers a speedy way to outsource feature fulfillment for the business’s long tail.
In fact, large numbers of third-party developers can fill so many niche feature requests over time that it can create a network effect for your business’s platform. After a product with a thriving software marketplace exists in a space, any new competitor has a lot of development work to do just to reach feature parity, and any unique features those competitors come up with could likely be reproduced by the incumbent platform’s third-party developers fairly quickly.
Successful software marketplaces can cement a company’s dominance within their product space.
Why is marketplace architecture so crucial to the business?
Software marketplace development is a risky business.
Marketplaces can offer immense value to a business, but must be architected carefully. A poorly-architected app marketplace could steer your product off the road. If the APIs you offer to third-party developers inadvertently encourage those developers to undermine your product’s core value-add or siphon off your users to their own platforms, your well-intentioned app store could be a catastrophic product mistake.
If your marketplace incentivizes third party developers to build features your users like, but which are bad for your platform in some other way, refactoring those features out of the marketplace architecture might annoy your users and make them leave.
Essentially, from the platform company’s perspective, launching a marketplace requires you to give up some control over your product. You surrender control of the areas in your product where you allow developers to modify things. Within those modifiable areas, your marketplace gives control over the results to your users, whose shopping habits decide what your product looks like to them.
How can we infer product strategy from marketplace architecture?
As outside observers, it can be difficult for us to see how a company wants its product to grow and change over time. By the nature of the medium, we are limited to reflecting on our own experiences as product users. However, software marketplaces offer outside participants the opportunity to turn this product-user relationship on its head.
Marketplaces let us consider developing within the confines of an existing product, becoming both users of the product and developers for the product. When you’re both a developer and a user within a product marketplace, the only limits placed on possible new features come from the architecture of the marketplace itself - what it does and does not let you change, and the incentive structures presented around those boundaries.
If we assume a certain level of intentionality behind the design of the marketplace, we can glimpse, through the rules of the game, what a company hopes for its product to become. At the very least, we can inspect the product’s “revealed product intent”, considering not necessarily how its creators intended for it to grow, but how its growth might actually play out in the future.
In this way, software marketplaces indirectly reveal product strategy through their architecture.
Let’s look at three examples.
Confluence
Confluence is a corporate wiki backed by the Atlassian Marketplace, where third-party developers publish apps which extend Confluence’s functionality. Different apps let wiki authors create and embed functionality like diagramming software, explorers for Google Drive directories, and more.
The developer experience
Under the hood, Confluence apps are HTML/CSS/JS snippets that are embedded into Confluence pages after being rendered from a Javascript-based runtime environment in Confluence’s backend. As an app developer, it feels a lot like writing a pre-rendered Next.js app that Atlassian hosts for you. You import Atlassian’s SDK in your code, write some app logic and JSX into a render function, and wire things together in a YAML file. Confluence renders your app’s front end in its own iframe, where you can either use Atlassian’s UI elements or bring your own.
As a Confluence app developer, you enjoy a similar degree of freedom in the backend. Your code runs in a contained environment within Atlassian’s cloud, but you can reach out over the network to external domains to offload work into your own cloud if you require more complex infrastructure. You can wire in your own database backend, compute cluster, or anything else you can imagine putting into a web app. Within your slice of the Confluence page, you have control over the entire stack.
The user experience
Atlassian Marketplace apps for Confluence have a lot of control over how they look and how they function - apps can modify the host product in all sorts of different ways. As a user, you can potentially get just about any kind of web app that you might want to embed into your Confluence pages. All you need is a third party developer to meet your demand - the marketplace does not meaningfully limit app architecture in any way. Different apps have different prices, which are automatically added into your monthly Atlassian bill, making it easy to start using apps.
Product insights
App developers and Confluence users have a lot of control over what they can buy and sell on the Atlassian Marketplace. Atlassian surrenders so much product control here because the marketplace creates a broad supply-and-demand-driven feature set for its platform. The marketplace cultivates apps that let developers embed whatever users want into Confluence pages - that’s the point.
Confluence’s product identity is “the single pane of glass for viewing your business’s internal information”. There are lots of different definitions of what that is across businesses, but if it’s viewable in a web browser, it can flow into Confluence. Maybe that’s where the name came from 😉.
Now let’s look at a second example of a platform with a very different architecture that cultivates a very different product outcome - GitHub Actions.
GitHub Actions
GitHub is a web app that lets you centralize your decentralized version control system, with a lot of other products bolted onto it. One of those products is GitHub Actions, which is GitHub’s built-in CI/CD offering. Using Actions, you can use “events” - pull requests being opened, code being pushed, comments being made, and more - to trigger “jobs” - running unit tests, building Docker images, deploying software, etc.
The developer experience
Developers can publish and share GitHub Actions which they develop for themselves on the GitHub Marketplace. As a developer, you can implement Actions as snippets of Javascript, shell commands, or as entrypoint scripts to Docker images. When users add your Action from the Marketplace into one of their workflows, GitHub runs your published Action on that user’s Action runner. GitHub displays the exit code and command-line output in the Actions tab.
In some ways, the developer experience when creating and sharing GitHub Actions is better defined by what isn’t available. You can’t extend the GitHub data model in any way, you can’t specify the runtime capabilities of the compute environment where your Action runs, and you can’t modify the structure or format of GitHub’s UI. For Actions, technical scope is tightly confined. You can only develop new functionality within a specific layer of GitHub’s application.
The user experience
By and large, GitHub Actions users are developers themselves, reusing Actions off the marketplace within their workflows to automate their CI/CD pipelines. The architecture is very flexible and pluggable for that specific use case - users can mix and match the Actions to their liking, reordering the Actions and triggering them with different events as necessary.
Because Actions are so simple to create and publish, there are a lot of them to choose from. CI/CD is a space where developers frequently end up building somewhat-similar solutions over and over. GitHub Actions reduce that repetitive tendency - for most commonplace CI/CD workflows, you can set up a large percentage of your desired functionality using existing Actions and only resorting to new, custom Actions when necessary.
Actions are available free of charge. Users pay for the compute time necessary to run them, but the $0 price tag for Actions themselves means that users (who are developers) can try out new ones without seeking budgetary approval first. This improves the user experience for developers, keeping them focused on coding instead of submitting spend requests.
Product insights
GitHub Actions provide a narrow marketplace offering. Actions can operate only within a tightly confined space, and don't offer a monetization strategy for third-party developers. However, the simplicity and ease of use that comes with that narrow focus contributes to their popularity with developers. Since developers are also users, this is a product for developers alone. GitHub Actions reinforces that with their marketplace architecture - Actions solves one problem for one group of people very effectively.
Because of this narrow focus, there is no room to extend GitHub’s functionality in any way to allow other business personas into the GitHub experience. The lack of UI extension and data modeling capabilities prevent third party developers from injecting things like ticketing software or OKR tracking into GitHub without hacking it in via a browser extension.
This approach is intentional - GitHub has other offerings like Issues, Pages, and Discussions that are intended to fill those other needs for their customers. Allowing third-party developers to offer those additional capabilities in a GitHub marketplace beyond Actions might result in internal competition and revenue cannibalization within GitHub’s platform.
Both of these previous examples examine a marketplace architecture in a single moment in time. Now let’s look at one in the middle of a refactor, which lets us infer product strategy change over time.
Slack
Slack is IRC with emojis, good UX, a dream of monopolizing business comms, and a promise to “end email”. Slack has an Apps Directory where third party developers can extend Slack’s UI in a variety of ways and a utomate workflows both inside and outside Slack. Slack is currently refactoring how Apps work, distinguishing between “traditional” Slack apps, which have been around for a few years now, from “new, modular” Slack apps, which are in beta.
The developer experience
As a Slack app developer, you have a lot of capabilities at your disposal. “Traditional” Slack apps let you:
- Create new tabs, modals, and message formats in Slack’s UI using Slack’s UI elements.
- Act as a bot within Slack by interacting with Slack APIs from your server using Slack SDKs.
- Receive and react to events within Slack by subscribing to or defining your own webhooks (which Slack will host for you).
- Interact with whatever public cloud services you like, authenticating with OAuth if necessary.
- Wire together different Slack apps using Slack’s built in no-code builder.
“New, modular” Slack apps can do all that, and also:
- Define your apps as Functions, which Slack will host for you and let other apps invoke.
- Create data stores, which are effectively SQL database tables, in Slack’s backend.
- Leverage several new flavors of internal and external triggers for Function execution.
- Manage your app's build-and-deploy cycle using Slack’s new developer CLI.
- Save and view log messages from your Functions using Slack’s app developer tools.
Notably, despite all of this complex functionality Slack app developers can use, there is still no way to monetize your published apps in Slack’s App Directory. More on that later.
The user experience
Slack lets users install apps from the App Directory and wire them together into workflows using its no-code Workflow Builder. While this functionality is not yet publicly available, Slack has announced that they intend to publish “new, modular” Function and Trigger components in this same way.
In other words, the next-gen Slack App Directory will contain not just apps, but individual functions, which no-coders can string together, giving users even more automation capabilities to build with.
Product insights
This developer ecosystem is complicated enough that there could be full time engineers whose entire job is to contribute to it. But how would they get paid? The fact that Slack still hasn’t added any monetization functionality into their marketplace makes it clear that they intend to operate how their parent company, Salesforce, operates.
Anyone who has worked in the proximity of a Salesforce installation can tell you that when you first buy Salesforce’s software, you’re only halfway there - after you pay Salesforce, you’ve got to hire a “Salesforce developer” to configure it for you. These “Salesforce developers” have learned the complicated intricacies of tailoring Salesforce’s platform to your company’s needs. They’re so common in industry that Salesforce itself even disambiguates the term “Salesforce developer” on its website.
Based on the direction their app marketplace is taking, Slack seems to be heading in the same direction. In time, “Slack developer” may become a job title, as more organizations begin to buy into their “low-code” model for workplace automation. Slack wants to become the single interface for workplace collaboration, communication, and automation - and a cohort of highly-compensated “Slack developer” consultants could be born to shepherd companies in that direction.
What does this mean for me?
As software engineers, the architectural decisions we make can steer the future direction of the products and companies we help to create. Software marketplaces lay that reality bare in a unique, publicly-visible way, and we can use them to learn more about a company’s intent behind its product. Regardless of your domain or application, your designs will likely have a similar impact. In a well-functioning organization, technical architecture and product strategy are tightly coupled to one another. That’s part of what it means to be a “tech company”.