Writer & Editor
Sorry, there is no results for this query
White-labeling and matchmaking occur when companies introduce technologies to each other. Call it technology word-of-mouth. These exchanges are particularly prevalent in marketplaces. Consider the standard components of an online marketplace: search, discovery, ordering, payment, and delivery. Any website composed of these functionalities creates a software ecosystem that can be shared – that is, duplicated by other companies to launch their own marketplaces. For example, the software used to run marketplaces like Amazon and Etsy can inspire smaller marketplaces that specialize in coins or rare books. Ecommerce marketplaces can spawn media streaming platforms.
In general, a standard marketplace ecosystem can be copied and run separately, to drive any marketplace that provides some form of search, discovery, ordering, payment, and delivery, as well as other features like ratings and recommendations. A sharable ecosystem introduces a way of doing business to other businesses. It can occur either on the front or back end – a company can share its website’s user interface technology or its back-end infrastructure. At Algolia, we see variations of both.
A marketplace is any physical space or digital platform that sells a variety of goods. Amazon, Ebay, and Etsy are marketplaces – single platforms that sell books, clothing, furniture, cars, and much more.
Under the hood, a marketplace can be composed of a single “headless” architecture and many moving components. What’s important for any stable ecosystem is how it chooses and manages its moving parts. Consider the software components that manage a website’s search and payment features. For search, two companies might use the same component but configure it differently. For payment, one might use Stripe to manage payments, another PayPal. A headless architecture allows this by using a plug-and-play system of software components – called APIs – that enable distinct components to interact with each other. The best APIs are jewels carefully carved by third-party experts. The job of the marketplace engineer is to integrate these APIs into their existing software architecture and configure them to meet their company’s specific business needs.
Once the architecture is built, and the components integrated and configured, you have an operational marketplace. This is where the white-labeling and matchmaking comes in: one marketplace website “inspires” different businesses by sharing its components. This sharing is done via partnering or white-labeling.
In this article, we’ll see how one successful marketplace paved the way for multiple spin-off marketplaces. Some spin-offs will use the same servers but switch components; others will copy the ecosystem onto their own servers and build unique websites. The next article in this series will dive into the technical details of how all of this is possible.
You can build a marketplace with one desk, two or three chairs, and some open laptops. In our scenario, there are two entrepreneurs with a talent for selling other people’s products. They’ve built a sensational brick & mortar marketplace for small-town artisans and antique dealers to sell their wares. They sell country-wide and people travel far to visit their store to discover hidden treasures. This is the definition of a successful physical marketplace.
The owners are dynamic. One is a sharp-witted promoter of local artists and dealers, who started the business and built it up with her winning personality and business smarts. Her partner, an engineering wizard, came in and laid the bricks and mortar, and also built the back-end business processes instrumental in making their marketplace a mecca for local artists and dealers.
For a long time, the engineer had ideas to go online. Online marketplaces like Amazon and Etsy convinced her she was on the right track. Covid 19 gave her no choice. She developed a powerful software ecosystem with a beautiful web design, creating the ideal user experience for a locked-in public eager to discover hard-to-find art and antiques.
As their online business grew, its technology and business merged. Merchandising and content discovery combined with simplified software processes for ordering and delivery. The platform offered an ideal search and discovery experience for the high demands of both consumers (demand) and vendors (supply). With talent and constant iteration, these women grew their digital marketplace to become the obvious one-stop shop for regional art and antiques.
All that with a desk and two chairs, now crafted in ebony.
Talent breeds talent. One entrepreneur’s breakthrough influences the next generation. In this case, an online marketplace built with a robust ecosystem and online-selling acumen led to spin-offs and partnerships.
In one scenario, a coin collector rose to the top of the search results. Every search invariably included his items. The women’s online marketplace put him on a larger map. But he felt it was not reaching his best audience – a very exacting niche of collectors who needed more details, dates, and histories. They needed an online search and discovery experience tailored to coin collecting. His clients liked to see every blemish and perfection, to be as close as physically possible to the coins.
This broke the model of a more generalized marketplace. What he needed was a different user interface – but not, as it turns out, a different ecosystem/infrastructure. So he contacted the engineer and they came up with a plan: her ecosystem, on her servers, would still manage his back-end data and business processes (like search and ordering), but she would decouple it from the front end, thus enabling him to build his own user interface to run on the same engine: two very different front-end interfaces integrated into one back-end infrastructure.
The main difference, therefore, would be the search and discovery experience. He wanted a user experience that spoke directly to all collectors, not only coin collectors. For this was going to be a collector’s marketplace for all kinds of collections – stamps, comic books, tapestries, vinyl.
Can you see the matchmaking?
The collector recognized how the original marketplace’s software components could run any marketplace, he just needed to customize it to his own business. This is an example where Company A introduces the individual API components to Company B.
A dealer of old vinyl records doubled as an aficionado of a local music scene. Like the collector, he conceived of a different kind of marketplace for musicians and performance artists. His inspiration came from Spotify and YouTube, but he recognized how the women’s marketplace ecommerce ecosystem could help him sell and stream other people’s music. So he contacted the engineer and learned that, with only a few modifications, her ecosystem could drive his streaming platform. She explained how the composable API-driven architecture enabled him to plug in components more suited for streaming – such as software for storing and streaming media or managing an artist’s royalties. Otherwise, the rest would be the same. She showed him how the 4-part model of search, ordering, payment, and delivery remained central (with “delivery” being changed to “streaming and/or delivery”). But to do this, he would need to purchase some of his own components.
At this point, the women saw an opportunity: Why not generalize their software architecture and sell it unbranded? White-labeling involves one business selling a generic version of their software to other businesses who then run the software on their own platforms and have complete control over its components and configurations.
Their first client was a group of contemporary art dealers already selling their art on the women’s marketplace. They wanted to branch off because their audience of art connoisseurs needed a completely different user experience. They followed the same partnership model of the collector, using the same infrastructure but changing the interface. Then their business jumped in profit due to the enormous prices and sales volume of some of their biggest artists. They needed exclusivity and more control over their business model and infrastructure. Therefore, they bought a white-labeled version of the ecosystem and made it their own, mixing and matching their own components with those of the original marketplace. A match made in heaven.
There are many other spin-off possibilities. For example, enterprise matchmaking, where Company A shares with other companies the components of its back-office systems, such as APIs that perform internal accounting, inventory control, and customer relations. The same logic of ecosystem matchmaking applies – one company creates a system with multiple components, exposes it to other companies (usually partners and suppliers), who then copy the processes and components, replacing some, configuring others.
I am sure at this point, the more technically-minded reader is asking – All this sounds very romantic, but isn’t the devil in the details? Indeed, there are details in the design, coding, and configuration that need to be carefully taken into account – but they do not have to be devilish. That’s the point of any API-driven, headless architecture: most of the details are already taken care of by the experts who build the third-party APIs.
Stay tuned for part 2 in this article series that will dive deeper into the ecosystem, focusing on the search and discovery component. We describe the content management (i.e., the searchable indexes) and front-end libraries that make the above scenarios possible.
Algolia Search and Discovery integrates closely with headless ecosystems. To find out how it can transform your digital strategies, sign up for free and see it for yourself. Or get a customized demo from our search experts today.