Let's play startup bingo? Platform, ecosystem, integration, marketplace, api, synergy. Bingo!
The topic of internal marketplace integrated solutions is very hot in the grocery world. We at Poster POS for ourselves understood the advantages of an open API and building an ecosystem for a long time I was particularly impressed with the chapter “The Platform” in the book “The Facebook Effect”, which reinforced the understanding that you need to go to the platforms. 3 years ago we opened the API, 2 years ago we launched the Marketplace, a year ago we launched a technology that allows us to seamlessly extend the functionality of the main product and influence its behavior, about 3 months ago we restarted the integrations catalog and began to actively market partners' applications.
When we started, I did not have enough public cases on this topic, a guide to action. In this article, I will tell you how a SaaS service without an integration catalog can become a SaaS service with an integration catalog. My article will be useful for products that have already passed the product-market fit stage and are ready to start building their ecosystem.
About us
To give a little context,
Poster is a SaaS automation system for the restaurant and retail business. What we do is called Point of Sale or “cashier”. Our product is divided into two parts - the terminal and admin panel. The terminal runs on tablets iPad and Android or Windows-based devices. At the terminal, cashiers and waiters drive in an order, accept payment, print checks. The owner of the establishment, the manager, the storekeeper work in the admin panel: they keep warehouse and management records, view sales statistics, manage goods, etc. Now 6000 active institutions in 53 countries of the world use the product.
A bit of history
The theme of marketplaces and platforms is not new. The first platforms are operating systems that allowed developers to not independently manage memory, i / o, processor time, etc. Then desktop applications began to appear with add-ons, plugins. My familiarity with plugins started with Total Commander and Winamp. Then there were Java applets for smartphones, iOS 2.0 released the App Store. Web services also began to grow into integrations and plugins, such as Facebook, SalesForce, Basecamp, Xero, etc. Open API and marketplace became a part of our daily life and we constantly face them.
What do marketplaces give?
More features, higher user involvement
Let's face it: your backlog will always grow. You will always have not enough resources to run all the functions that your users are asking for. Moreover, if you constantly add new features to the product, sooner or later it will turn into an eerie, uncomfortable mess of buttons, checkboxes and switches. It is better to make a product that will qualitatively solve 3-7 tasks than 50, but mediocre. Therefore, the integration helps the product to grow qualitatively in the eyes of the user, expand its functionality, and therefore less likely that your client will go to competitors.
Growth driver for your sales
Integration with other companies in the market can be a good sales driver for your main product. For example, in our case, potential customers with obsolete cash register software or without it at all may come to partners who are engaged in loyalty systems. At this point, the partner will recommend the one with which he has integration and good relations.
Ability to make non-standard solutions for large customers
Previously, when we received a request to refine a product on a large network with atypical requirements, we had to refuse, in order not to bury ourselves in the pit of enterprise-solutions, where at every step in the code there are branches like:
if (account==='very_important_enterprise_customer') { ... }
Now we can implement almost any add-ons in the system without affecting the core of the product. Or, even better, to give improvements to outsource.
Additional earnings channel
Usually directories take a commission from sales of applications that are placed in it. The size of the commission is from 30 (industry standard) to 80% (in very extreme cases, for example, in Odnoklassniki). But at the same time, I personally have little faith in the idea that the company's business model can be built around the marketplace. For example, Apple has 62% of its revenue from selling the iPhone, and the entire category of services (applications in the AppStore, Apple Music, iCloud, Apple Pay) - 13%. In our case, we set the task for the marketplace to be self-sustaining.
What are the integration
We have divided the integration options into 3 main types: Backend, Manage platform, POS platform.
Backend integration
The most basic integration option, we started with it and the first integrations worked in this way. Backend of the partner service through the HTTP JSON API gets the data, somehow processes it and displays it to the client, maybe it updates something inside our system. An example - systems of analytics, loyalty, mailings, video surveillance.
Manage platform
Essentially the same backend-integration, but built into the user's personal account. Under the hood for this is the usual iFrame and its protocol for seamless authentication. Much more convenient for the user, because no need to leave the system anywhere. Suitable for applications with a simple interface.
POS Platform
At some point, we and our partners began to lack backend integration. It was necessary to directly integrate with the cash register, I wanted to expand the functionality, natively integrate into the cash register, change its behavior. Therefore, a year ago we launched the POS Platform with the mechanics of plug-ins or widgets. You could see similar solutions on the web, for example in Trello.
Examples of integration on this technology are loyalty systems that require guest identification near the cash register, mobile wallets and other payment systems. Here, for example, is an application from Paytomat that allows you to pay for an order with cryptocurrencies:
Further I will tell about the technical component of the implementation of this technology.
How to make a JS-application, extensible by third-party developers
Our cash solution is built on hybrid technology, which allows it to be supported on all platforms: iOS, Android, Windows. The whole interface and business logic is written in HTML / JS. And for native platforms, we write wrappers around WebView and implement drivers for working with peripheral equipment (printers, fiscal recorders, scales, etc.)
If you also write an application on the web stack, I will save you time for research and tell you how we made the application extensible. In the process of learning, they were inspired by the decisions of Trello, Shopify and Atom.io. As a result, came to the next model.
The main application instance creates a separate container for each connected third-party widget. The container is an iFrame in which the JS file with the executable code of the partner application is loaded. In the container methods are automatically available with our API. The container is cached on the front (Appcache or Service Workers) and can run, work without the Internet.
The iFrame solution allows you to isolate the logic of a third-party application from the main application and, in the event of any problems with the widget, do not break the main flow of the cash register application. We also considered the option with WebWorkers, but the scripts inside the worker do not have access to the DOM, and we give widgets the ability to display interfaces, so this option was dropped right away.
Developers write their application using JS or any language compiled into JS (CoffeeScript, Typescript ...), with any frameworks or libraries. Further, the code and all the resources of the webpack are collected in one bundle.js, which the console utility deploys to us on the servers and delivered to users.
Widgets in iFrame exchange messages with the main application via postMessage and can send commands to the checkout via the Poster object built into the global scope. For example:
Poster.interface.popup({width: 500, height: 300, title: " "});
We implemented a callback queue, which allows third-party applications to subscribe to cash register events, respond to them and change the application's logic. For example:
Poster.on('beforeOrderClose', (data, next) => { alert(" "); next(); });
By the way, in the case of before * events, which, in fact, block the work of performing some operation at the checkout, we had to enter the response time from the third-party widget. For example, there is an application that listens for the beforeOrderClose event and makes a request with the details of the order, which the cashier plans to pay, to his server. So that the user experience does not suffer, we give the application no more than 5 seconds to implement its logic and call next () or display an interface that will show the user progress.
Dev mode
Each time it is inconvenient to assemble the entire application and deploy it to us on the servers in the development process, so we did a dev mode. In it, the widget is constantly assembled with the help of webpack-dev-server with hot-reloading and in the cash register application on the developer’s account, the application code is launched not from production, but from the local developer’s machine. In this case, the interface is always possible to switch between dev and prod. Soon we will introduce another branch - beta. The beta code will also be sent to us on the server, but will be available only to beta testers of the application.
Developer Cabinet
For a long time, we registered applications and changed the settings manually, at the request of the developers. Each contact at the stage of creating an application allowed us to communicate more with developers, to learn about what products they want to integrate, what methods they lack in the API.
But when we reached 40-50 simultaneous integrations, the mechanical work began to take a lot of time for the integration team. Therefore, we launched a developer’s office in which we automated all these processes.
Documentation, examples, partner support
We have high-quality technical support in the company's DNA. Therefore, when we began to grow the story with development partners, we decided to make the strongest developer support on the market.
We communicate with each partner, we help to make a flow integration and we even prepare a detailed follow-up with a list of methods that they need to use for implementation. We answer questions in the general Telegram-chat with partner developers.
By the way, sometimes there is a problem when less experienced developers ask questions not on our platform, API, but simply on programming or do not want to debug when the problem is on their side. In such situations, we use the “do not respond within 1-2 hours” method, in most cases during this time the developer solves the problem on his own :)
For documentation use Slate. The auto-generation of documentation from source code comments didn’t work for us because we need to support several language versions of the documentation - Russian and English.
And of course it is important to understand that for third-party developers we are just one more additional integration, so they should do it as quickly as possible and with maximum benefit for their business. Therefore, we make
ready boilerplate , code samples and do our best to help in the process.
Application marketing
In order for everyone to benefit: institutions - additional functionality and solution of their business problems, developers - new customers, and we - deeper closure of customers in their ecosystem, applications need to be marketed. For marketing applications among our users, we use the following tools.
Integration announcement
This is the simplest thing you can do: announce a new integration in social networks and a monthly newsletter about new features. Messages are received non-targeted, for all of our contacts, and can be lost among the information noise.
Trigger mailings
We allocate customers who may be interested in one or another category of applications (loyalty systems, video surveillance, workflow, etc.), and we make them point mailings with a proposal to see what we have in the market from this category.
For example, for establishments that have scored more than 100 contact details of their guests in the database, we make a trigger about integration with loyalty systems and tell that he can work with his guests even more effectively and return them to his establishment. For establishments with more than 5 employees (this is no longer a family business), we send a trigger for integration with cloud-based video surveillance systems so that employees can be easier to control.
We add this letter and push to our structure of onboarding, it comes to the client when he has already become paid and started using all the main functions. If you send him information about the extension of the functional before he learns to use the main one, it will be absolutely useless.
Information banners inside the product
Users quite often ignore letters and pushes in the stream of information garbage, so we added unobtrusive banners in the product itself. We found that this is one of the most effective ways to send traffic to the application page. Banners appear in context. For example, a banner about products for deep analytics appears in the section with checks - where the owner analyzes his sales.
What else?
Now we are experimenting with the format of blog articles with business problem solving cases using integrated solutions. Soon we will launch joint webinars with partners.
With the tools listed above, we learned how to bring third-party developers 20-100 leads per month, and this is just the beginning.
After the transfer of the lead
Naturally, the sale does not occur by itself after we bring the lead to a third-party developer. Usually, b2b-products are more difficult to master and work on their own, so we pass on the contact details of the client (with his consent) to partners and insist that customers be contacted and helped in the process of onboarding.
What do we have in work?
Billing
We believe that the client should be billed in one place in order to maximally simplify the flow of work and connections for it. Now we are finishing billing support for third-party applications.
By the way, there are many difficulties in implementation, for example:
- Applications may have a completely different monetization model: monthly subscription, transactional payments, subscription depending on usage.
- The client must be automatically notified in case of a change in tariffs.
- Customers can pay from different countries, and a contract with a partner is usually in one
- A client may have a card attached for payments, or there may be a payment on invoices on the legal entity. face.
App review
Now review of the application is carried out once when the application is in the market. We want to introduce a mandatory, but quick review for each delay to help track some edge cases.
Guidelines for third-party applications
In order to keep a single experience from using our product and integrated products, we give recommendations on design and flow to partners, but there is no formalized set of rules yet.
We develop guidelines for internal use by Poster designers and developers, and then open them to third-party developers.
That's all
In fact, we are only at the beginning. There is still a lot of work to become a full-fledged platform, but we have already learned a lot during this time. Further - only more interesting. If you have questions, write in the comments, I will try to answer as fully as possible.
And if you make a product for cafes, restaurants, shops - let's change the market together! Write now at
dev@joinposter.com , I am sure that we can be useful to each other.