Custom development of a multi-vendor marketplace: Merkato

Merkato is a multi-vendor marketplace: it is not a store, it is a platform where every business creates its own and sells inside a shared storefront. This case shows how it was built from scratch with custom development on PHP, and which pieces have to be solved when products from different sellers live in the same catalog.

The project was delivered in over three months, reached six integrated stores and recorded 85% more aggregated traffic. These are the decisions that made the platform hold up to the model.

The challenge: a platform where others sell

An online store has a single seller: the company. In a marketplace the platform is the storefront and the seller is a third party who registers, publishes products and manages orders. Everything that is an internal decision in a store has to become a feature of the system here.

Sellers who are not technical

Someone who wants to sell will not read a manual: they have to be able to open their store and publish products in minutes, from the browser and unaided. Every extra step in onboarding is a seller who leaves before uploading their first product.

A catalog with products from many origins

Visitors do not buy "in a store": they come to the marketplace, search and compare. Products from all sellers have to live together in one catalog with categories and a search that works the same for everyone, without the buyer needing to know who each item belongs to.

Splitting every sale without friction

As soon as there are several sellers, each transaction stops being a single income: it has to be split between the platform and the seller according to defined rules. That is the piece that most shapes the design, because it affects the order, the payment and what each seller sees in their reports.

The solution: custom development on PHP

The whole platform was built from scratch on PHP and MySQL, without starting from an off-the-shelf solution. The reason is simple: the product is not a store, it is the business model — how a seller registers, what each one sees, how every sale is split and how all the stores live together in one storefront — and those rules are implemented exactly as defined, without bending the business to whatever a template allows.

Registration and your own store in minutes

Seller onboarding was solved as a guided flow: they register, set up their store and start publishing products without depending on anyone. For that to work, the platform has to solve behind the scenes what the seller does not see: permissions, available categories and publishing rules.

A management panel for each seller

Every store has its own panel to manage products and orders, so each seller works on their own without access to anyone else's. This is the part that makes a marketplace sustainable: the platform does not handle by chat what each seller can do on their own.

Unified catalog, global search and commissions

Products from all stores are grouped in a shared catalog with categories and a new arrivals section, with a global search that covers the whole marketplace. And every transaction is split between the platform and the seller according to the defined rules, with that information visible in the seller's panel.

How we implemented it in over three months

Before coding, the rules of the model were defined: how a seller is onboarded, what each role can do, how each sale is split and how the shared catalog is organised. With that settled, development moved forward in blocks and the final weeks went into testing the system with several stores running at once.

Business rules before screens

In a marketplace the interface is the easy part: the hard part is deciding what happens when a seller does not comply, how their share is calculated or who can see an order. Documenting those rules at the start avoids rebuilding half the system three months later.

Testing with several stores at once

The system was tested with several stores operating in parallel: publishing, searching, ordering and splitting. It is the only way to catch the problems that only appear when the catalog stops being a single seller's catalog.

Results

The platform was delivered with the seller flow and the catalog tested. These were the needs of the project and how they were solved:

The measured result of the project: six stores integrated into the platform and 85% more aggregated traffic. That is what a marketplace is after — more sellers bringing more catalog, and more catalog bringing more buyers — and it only works if onboarding and management are simple enough that sellers do not walk away.

What a multi-vendor marketplace needs

If you are thinking about building a platform where third parties sell, these are the points that decide whether the model works:

• Frictionless seller onboarding: if opening the store is hard, no catalog will save it.
• Business rules defined before coding: commissions, roles and permissions are the skeleton, not a detail.
• A shared catalog with global search: the buyer should not know — or need to know — who each product belongs to.
• An own panel for every seller, so the platform does not have to handle by hand what each one can do alone.
• Testing with several stores at once, because marketplace problems appear exactly when different catalogs live together.

If your project is a platform rather than a store, our services page explains how we work, and you can write to us to go through it together.

Frequently asked questions

What is a multi-vendor marketplace and how is it different from an online store?

In an online store there is a single seller: the company. In a multi-vendor marketplace the platform is the storefront and every business that registers gets its own store, products and orders. That forces you to solve things a normal store does not need: seller onboarding, permissions, commission sharing and a shared catalog mixing products from different origins.

Why custom development instead of an off-the-shelf platform?

Because the product is not a store, it is the business model: how a seller registers, what each one sees, how every sale is split and how all the stores live together in one storefront. With custom development those rules are implemented exactly as defined, without bending the business to whatever a template allows.

How are commissions on each sale handled?

Every transaction is split between the platform and the seller according to the defined rules, and the seller sees in their panel what they have sold and what is theirs. It is one of the pieces that most shapes the design of a marketplace: it is best defined before coding, because it affects the order, the payment and the reports.

How long does it take to build a multi-vendor marketplace?

This project was delivered in over three months. The schedule is set by the pieces that must be solved: seller registration and store, management panel, unified catalog with search, commissions and end-to-end purchase testing with several stores at once.