Get best of the week

How we started the marketplace of applications in the SaaS service

Hello everyone! I am Oleg Neklyudov and work at MySklad, the largest SaaS service for trading in Russia. For 13 years we have been automating trade management for small and medium-sized businesses. Now we are doing a marketplace of applications to represent in it a community of different services that are functionally related to our product.

There are several tasks for the marketplace. Firstly, it is necessary to expand the capabilities of users of our service using vendor applications. It is necessary to integrate the service with other products. The marketplace will also help small development companies enter the market and profit, reduce sales and marketing costs.



Our product is a massive service for trade, and therefore we have access to an audience of one and a half million SME representatives: owners of retail and online stores, wholesale companies, small enterprises. The daily audience of the service is 60,000 users. Clients can work with the service on all platforms and devices. Due to the extensive user base and using the API, any developer can make an application for our audience.

Marketplace. Background


Two years ago, we had a good starting position.

Firstly, to implement the marketplace, you need a good functional API so that developers can receive the necessary data and automate processes. We already had such an API.



Secondly, our partners have already developed dozens of integrations.

Thirdly, as many of our own integrations worked - we did what we thought was in demand for our customers: exchanges with banks, integrations with mailing services, telephony, engines for online stores.



Fourth, our large user base, part of which buys integration and brings money.

We understood that it is not important for the client whose solution he will use, ours or partner: the user simply goes into the application window and selects the one that he needs.

We looked at the market and saw that many large SaaS services already have a marketplace. This confirmed the efficiency of such a model and the availability of adequate benefits for all project participants.



Who needs a marketplace


And to us, and vendors, and our users, but for their own reasons.

What is the B2B service marketplace for?

Firstly, it increases user loyalty by increasing useful functionality, allowing them to most fully automate business processes.

Secondly, this is money - increasing the average bill from the sale of paid applications plus to the main subscription.

Thirdly, things that are strategic for us: moving the product towards an IT platform, the emergence of new expansion points and increasing opportunities for flexible customization.



Why marketplace vendor?

We have two types of vendors.

The first earn on applications and implementations. They are focused on the creation of paid applications. And they want to sell them through us.

The second is service providers such as courier companies and other SaaS services. They take money for their services, and they are interested in gaining access to a huge audience of our product. They do this through free apps.

What is the marketplace for the user?

Clients receive enhanced functionality for business, can choose from a range of integrations and independently “spin” our product using new expansion points.

Hence, more satisfaction from the service and increased loyalty to it, and this affects the financial result.

Marketplace Development Strategy


Important insight: the client for the marketplace is a vendor, not a user of a SaaS service! It's simple - it’s the vendor who invests its resources in application development.

In fact, the vendor leases the space inside our service, publishes the application and pays the rent as a percentage of user payments. The vendor himself determines what products he wants to put in the marketplace.

We strive to have more applications in the market and they bring money / installations - here we talk only about clients of the SaaS service indirectly. All emphasis on the site, vendors and applications.

We took the first steps with partners whom we have known for a long time. They already had good integrations with our product, and we invited them to pack ready-made solutions in applications for the marketplace, publish and try to make money.

We discussed what should be in the product - we carried out a full-fledged customer development. We not only talked about our requirements for integrations, but also tried to understand what technical capabilities our platform companies must also have to accommodate these integrations.

Almost immediately, we formed an approach: when planning to develop one or another feature of the marketplace, we immediately see which specific applications will use this feature.

Our task is to minimize, and ideally reduce to zero, the time from the release of a feature to the first published applications using this feature. So we take care of the effectiveness of our development process from the product point of view at the planning stage. And not only through the use of released features, but also through the implementation design based on specific cases.



How do we select marketplace participants and features for development


If a vendor contacts us with a desire to make an application for our marketplace, but it requires improvements / features from the platform, we evaluate the priority of these improvements, based on the potential demand for these applications.

Not every vendor will come to us: there is still a selection.

First of all, we focus on the level of utility of the application for our users and potential revenue. Market size is important.

Secondly, it is important to look at current development plans in the company as a whole and coordinate them with plans for the marketplace. This allows you to move forward most efficiently, using the results of other teams and not duplicating the same functionality in different parts of the system. For example, we use our common billing system in the marketplace - for applications, and the general partner authentication service - for the vendor’s personal account.

It is important to understand the timing of the release of the application - you should not delay the implementation.

We also have an internal motivator that makes us actively fill the market - corporate OKR, we set them ourselves last year. They suggest very specific figures, for the achievement of which it is necessary to constantly accelerate. Already in 2019, OKR recorded: 20 applications developed by vendors, and 700 installations of new applications on active accounts in the service. In 2020, we already have more than 5,000 installations, about 70 vendors are registered in your personal account and are developing applications.

We still have not so many vendors, which means that the "clearing" is empty from the point of view of competition. According to the plans for the year - an increase in revenue from applications, and here it is clear that if it increases with us, it means with vendors. We are also expanding the capabilities of embedding the service in the user interface, and this opens up completely new possibilities for applications. People will see them constantly and gradually get used to using it. In 2020, this will become a growth driver.

Marketplace launch history


It all started with the development of the API, and the first versions were not entirely successful. We now have the JSON API, which has gained popularity and is actively developing. It allows you to access the vast majority of user information objects. You can read, delete, update and create everything. This opens up very great opportunities for integration and application functionality. We monitor the backward compatibility of our APIs to ensure seamless integration.

A few years ago we also developed specialized APIs for cloud telephony and loyalty systems - you can quickly connect new vendors in these areas.

By combining on one page our integrations and the first integrations in telephony and partner loyalty systems, we got the first showcase of applications. This was not yet a full-fledged marketplace, since they were published manually by developers, from third-party vendors there were only highly specialized applications, it was not possible to host “general purpose” integrations (using the JSON API) from third-party developers.

It's time to do a marketplace.

The first attempt to make a marketplace


And she was unsuccessful. Why?

Firstly, there were not enough resources. We did not consider the marketplace as a separate and self-sufficient product: it was just one of the epics in the overall product development.

And now it's different.

Now there is a separate marketplace team with its product, developers and testers. With the strength of seven people, we apply and develop everything that is needed to create a large IT supermarket.

We started the development of the marketplace by transferring the existing telephony applications into it - in order to start from something, create structures and forget about it all.

Then we packaged some solutions into very simple iframe applications: they showed third-party services in tabs inside our service. For this, two early adopter were chosen, with which they made simple integrations. It was a simple and effective step - it was necessary that the first vendors appeared as quickly as possible with us and were able to make sure that everything works well.

The fears here are understandable - not everyone wanted to invest “without trial” in development, but these very simple applications allowed them to understand whether our customers have an interest. An example of such a vendor is the "on_helf" service. Starting the first applications in the marketplace as quickly as possible, we fueled the interest of other vendors.

Next, we made it possible to host full-fledged applications that, after installation, begin to exchange data with the service through our JSON API. In fact, it was our MVP.

At the stage of the emergence of MVP, we built a special environment called Sandbox. We roll out large features into it in the alpha version so that vendors can begin to develop and debug their applications in advance regarding these features. So we implement the point of our strategy - to release a big feature along with applications.

In the case of MVP, it was like this: at the time of release, the vendor was already developing and debugging applications in the Sandbox, and some solutions were ready. As a result, only a few days passed between the release of MVP and the publication of the first applications for it.

As the next step, we added paid applications to the market with the simplest option of billing in the style of Fix Price - worth 500 rubles per month. This simplification allowed us to launch sales in the market as quickly as possible.

At first, there was no vendor personal cabinet on the site. Interaction with them was in manual mode: vendors transmitted information to us, we entered it through the internal admin panel. On a small pool of vendors, this worked well and allowed us to shorten the release time of MVP. Now the vendor can independently launch applications through the personal account in the market and manage them.

After the release of the first version of the vendor’s personal account, we returned to the active development of paid applications and made several major features:

  • — 1 14 . ;
  • — , . . ;
  • : 500 .



?


We continue to move and are working to increase the number of vendors (by the way, submit an application )!

We are not slowing down the pace of releases for prod: there are many of them small, but they are constant.

The main direction we are working on now is the ability to flexibly integrate applications into the service's UI.

We started with widgets - we enable applications to embed UI parts in counterparty cards, goods, orders and other entities. Many vendors really lack this functionality.

We are not limited to widgets: custom actions and columns in the lists of entities and documents, modal dialogs, the ability to communicate widgets of one application with each other, reuse of existing interface service objects by applications, for example, selectors and dialog boxes, and much more.

We will develop widgets through vendor cases. We ourselves decided to get into the shoes of these companies and implement a large application feature of the main product as a separate application that actively uses the functionality of widgets.

We decided to kill two birds with one stone. On the one hand, we are sawing a useful feature for users - it is in demand by wholesale companies, customers of our service. On the other hand, making a feature in the form of our own application for the marketplace, which embeds its widget in the counterparty’s card, we continue to drive the widget mechanism in the platform on a specific case. But of course, there are several cases from vendors.



And some life hacks


Can I?

Do you have your own product, for example, a SaaS service, and you think it’s time to make a marketplace or too early?

Evaluate two things. The first is integration with your product and developer APIs. The second - you should have enough users so that vendors would be interested in making applications for your marketplace.

I can, and what to do next?

Solve:

  • who and how will create and develop a marketplace: will it be a separate team or will it be necessary to use the resources of colleagues who are engaged in other tasks;
  • where to get vendors with applications;
  • what to do first thing;
  • how vendors will debug applications during development and what tools they need to support applications after publication.

If you are a vendor, then what to think about:

  • — ;
  • : , , ;
  • . , . , ;
  • : ;
  • : , .

, :

  • , ;
  • ;
  • .

, :

  • ;
  • , , .


We see the marketplace as a very good, inexpensive and easy way to increase the level of automation in small and medium-sized businesses.

I believe that such platforms with applications inside will increase the connectivity of information systems - there are many small non-competitive niches that large developers are not relevant to deal with, and for small companies and individual developers - that’s it. This is their bread, and by earning, they will close the gaps in the automation of small businesses.



We have already received more than a hundred applications from vendors for placement, we are discussing the implementation of these integrations, we have good experience in quickly launching applications, and this gives us reason to believe that the marketplace has taken off.

More articles:


All Articles