Multivendor Marketplace Platform
One branded marketplace, many independent sellers — with the money, shipping and governance that make it work.
Who it is for: An operator building a marketplace for a sector, a region or a group of merchants — anyone who wants sellers to onboard and fulfil while keeping approval, catalogue standards and settlement under their own control.
Per vendor
Orders, shipping and payouts split automatically
2 models
Charge subscription, commission, or both
Self-serve
Vendors register, upload documents, await approval
EN + AR
Bilingual, right-to-left included
In one paragraph
Three separate applications on one shared foundation: a storefront for shoppers, a dashboard for vendors, and a dashboard for you as the operator. The hard parts of a marketplace are already built — one customer order splits into a separate order per vendor, each vendor ships and is paid separately, and money moves through customer, vendor and marketplace wallets with a ledger behind it. You charge vendors a subscription, a commission on their sales, or both — the platform runs either way.
The three sides
Storefront
Browse, search, buy, track, return and review across every vendor.
Vendor dashboard
Register, list products, fulfil orders, ship, and see what they are owed.
Admin dashboard
Approve vendors and products, govern the catalogue, run billing and settlements.
The decisions behind it
Any platform can list features. These are the three choices that shaped this one, and what each cost us.
- 01
Both revenue models, because the right one depends on you
The problem
Commission is the default marketplace model and it has two costs: it punishes exactly the sellers you most want — high volume, thin margin — and it makes your revenue a function of someone else's month. But a flat subscription is wrong for a marketplace of occasional sellers, who will not pay monthly to list three items.
What we chose
We built both, and the billing layer treats them as interchangeable rather than as a fork in the codebase. You can take a percentage, charge a subscription, or run both together. It cost more than picking one, and it is the reason the same platform suits a wholesale marketplace and a crafts marketplace without a rewrite.
- 02
One order the shopper sees, many the vendors do
The problem
A single cart across four vendors is four fulfilment obligations with different couriers, rates and timelines. Show that honestly and checkout becomes incomprehensible; hide it and the shopper cannot understand why half the order arrived.
What we chose
The order splits into a separate order per vendor at checkout, each with its own shipment lifecycle, returns and settlement. The shopper still sees one order with its parts, and shipping broken down per vendor before they pay. Everything downstream — refunds, returns, the financial dossier — had to be built against the split rather than the whole.
- 03
Three applications, one foundation
The problem
Marketplaces usually grow three codebases. A fix lands in the admin dashboard and not the vendor one, the two drift apart over a year, and eventually nobody can say with confidence what a vendor actually sees.
What we chose
The storefront, vendor dashboard and admin dashboard share one design system, one set of translations, one data layer and one component library. It made the first month slower and every month since faster, and it is why a permission change is enforced identically in all three rather than in whichever one someone remembered.
How it fits together
The shape of the system, not its wiring. Every application is built on one shared foundation — the same design system, translations, data layer and components — so a fix lands everywhere at once and the interfaces never drift apart.
What it does
What shoppers get
- One cart across vendors, with shipping broken down per vendor at checkout
- A single vendor's own storefront page alongside the whole catalogue
- Products with options — the exact combination's price, stock and photos
- Orders that show their per-vendor parts, cancellation and returns with photos
- Wishlist, wallet, reviews and notifications
- Structured data, sitemap and correct link previews, so it is found on Google
What vendors get
- Self-registration with document uploads — and your approval before they go live
- The same product builders your own team uses
- Only the slice of each order that belongs to them
- Their own shipping rates, conditional rules and couriers
- Their own coupons, scoped to their own products
- Wallet balance, what each order settled to, and remittances with proof of payment
Governance
- Vendor applications to approve or reject, and the ability to act on a vendor's behalf
- Product approval — nothing reaches the storefront unapproved
- A review moderation queue across the marketplace
- Admin, vendor and customer audit trails
- 24 dashboard areas granted or withheld per role, enforced on the server too
Money
- Subscription plans, commission rules, or both — whichever model you run
- Settlements and remittances, recorded with proof of payment
- Three kinds of wallet — customer, vendor and marketplace
- A per-order financial dossier: what the customer paid and what the vendor is owed
- The marketplace finance journal behind all of it
Catalogue & merchandising
- One shared attribute library, so the catalogue stays consistent and filterable
- One category hierarchy for the whole marketplace
- Marketplace coupons alongside vendor ones
- Scheduled ad placements across the storefront
- A media library, and where every asset is used
The storefront's look
- A home page built from widget rows on a 12-column grid, published when ready
- An About page builder and content pages that feed the footer
- Five ready palettes or your own colours — live within seconds
- 33 dashboard themes, per user, across both dashboards
Why it is built this way
One shared foundation
The three applications share their design system, translations, data layer and components. A fix lands everywhere at once, and the vendor and admin dashboards never drift apart — which is the failure mode that makes most marketplaces expensive to maintain.
Two revenue models, not one
Take a commission per sale, charge vendors a flat subscription, or run both at once. Commission scales with the marketplace but punishes high-volume, thin-margin sellers; subscription makes your income predictable and gives those sellers a reason to join. Which suits you depends on your sector, so the platform does not decide it for you.
Bilingual to the core
English and Arabic throughout, with the whole interface flipping to right-to-left. Written translations, not a machine pass — because a store your customers can't read in their own language isn't a store.
Permissions enforced twice
A screen someone may not open isn't shown to them, and the server refuses it as well. Hiding a button is not access control.
Type-checked end to end
The codebase is TypeScript throughout and checked before any build is allowed through, so a change that breaks a contract fails at our desk rather than yours.
Settings take effect immediately
Your name, logo, colours, home page and policies update the live site within seconds. No developer, no redeployment, no waiting on us.
Built with
Not standard, but available
There is a live version. Ask us for it.
Both platforms run on staging with real data in them. We don't hand out the link publicly — tell us what you sell and we'll open access and walk you through it, so you see the parts that matter to your business rather than a generic tour.
Usually opened within a day.
Want a walkthrough?
We'll show you the real dashboard, end to end, and tell you honestly what setting it up for you would involve.
Book a walkthrough