Multi-vendor marketplace development
A marketplace is three products wearing one brand: a place customers want to buy, a back office vendors will actually log into, and an operations console your team runs the business from. I build all three, on one backend, with the money handling done properly.
Built for these situations
- Founders launching a category marketplace who need vendor, admin and customer surfaces together
- Retail or service groups turning an existing supplier network into a platform
- Businesses whose current marketplace cannot handle commissions, payouts or disputes
- Teams that need bilingual Arabic/English commerce from launch
Not a fit if
- Single-vendor stores — you do not need marketplace complexity or its cost
- Marketplaces with no supply side lined up; software will not create vendors
- Anyone expecting a fixed price before the transactional model is agreed
What usually goes wrong
Vendors will not use the dashboard
If listing a product takes eleven clicks and payouts are invisible, vendors go back to phone orders. Supply-side UX is a commercial risk, not a design preference.
Commission logic lives in someone's head
Different categories, vendors and campaigns carry different rates. Once that logic is manual, every payout run is a negotiation and every month closes late.
Orders stall between vendors
A basket spanning three vendors needs three fulfilment states and one customer-facing status. Platforms that model only one order state produce daily support tickets.
Nobody trusts the numbers
Refunds, partial cancellations and wallet credits quietly break naive balance columns. By the time it is noticed, the correct figure is unrecoverable.
What Makhloof Studio actually delivers
Customer storefront
Search, category browsing, multi-vendor cart, checkout, order tracking and returns — server-rendered for SEO, bilingual with full RTL, fast on a mid-range phone.
Vendor back office
Onboarding and verification, catalogue management, order queues, stock and pricing, staff permissions, and a payout statement the vendor can reconcile without calling you.
Operations console
Approval queues, dispute handling, commission rules, payout runs, campaigns, delivery zones and analytics that answer questions rather than decorate a page.
A money layer that survives audit
Idempotent payment handling, an append-only ledger, derived balances and traceable commission and refund entries — the same approach used on MONTRA's B2B platform.
Shipped, not theorised
Every claim on this page maps to a case study you can read in full.
Typical modules
A realistic scope for this kind of build. Yours will be a subset — the first call is where we cut it down.
Marketplace core
- Category and attribute-driven catalogue
- Multi-vendor cart and split checkout
- Order lifecycle with per-vendor states
- Shipping methods and delivery zones
- Returns, cancellations and disputes
- Reviews and vendor ratings
Money & settlement
- Card, wallet and cash-on-delivery payments
- Configurable commission rules
- Vendor wallets and payout runs
- Coupons, cashback and store credit
- Refunds with full audit trail
- Financial reports and reconciliation
Growth & retention
- SEO-ready category and product pages
- Push, email and SMS notifications
- Campaigns, banners and featured placement
- In-app chat between buyer and vendor
- Loyalty points and repeat-order flows
- Native apps on the same backend
How this gets built
- 01
Agree the transactional model
Who charges whom, when money moves, what a refund means and who bears delivery cost. This conversation shapes the schema, so it happens first.
- 02
Build supply before demand
Vendor onboarding and the vendor dashboard ship early, so you can recruit and load real catalogue while the customer surface is still being built.
- 03
Weekly clickable previews
You see working software every week on a real URL. Course corrections happen while they are cheap.
- 04
Production hardening
Dockerised deploy behind Nginx, CI/CD, backups, monitoring and a clean handover with an agreed support window.
Typical stack
Worth knowing before you write.
A short, honest filter. It saves both of us a call that was never going to work.
A good fit if
- You have a real business or a funded idea, and a decision-maker in the room
- The product has to handle money, roles, or operations correctly — not just look good
- You want one senior engineer accountable end to end, not a rotating team
- Arabic and English both matter to your market
- You can give a few hours a week to reviews and decisions
Not a fit if
- You need a team of ten starting Monday — that is an agency's job, not mine
- The budget is fixed before the scope exists and cannot move
- You are looking for the cheapest possible quote rather than the right build
- Nobody on your side can answer product questions within a few days
- You want equity-only work or an unpaid prototype
What you get in the first call
Fifteen minutes, free, no deck.- A straight answer on whether this is buildable the way you imagine it
- The two or three decisions that will drive most of your cost
- A rough shape: phases, surfaces, and where the risk sits
- An honest ballpark range — or a referral if I am not the right fit
What to prepare
None of it has to be polished.- One sentence on what the business does today
- The workflow that hurts most, described in plain language
- Who needs to log in, and what each of them does
- Any deadline that is real, and why it is real
- A budget range you are comfortable discussing openly
Answered straight
- Should we use an off-the-shelf marketplace platform instead?
- If your model is standard products, standard commission and standard shipping — yes, and I will tell you so on the call. Custom pays off when the transaction is unusual: RFQ negotiation, service bookings, per-category commission, multi-branch vendors, or Arabic-first operations that generic platforms handle poorly.
- How do you handle payments in Egypt and Saudi Arabia?
- Through the regional gateway that fits your entity and settlement needs, plus wallet and cash-on-delivery flows which still carry a large share of orders in both markets. The payment layer is abstracted so a gateway can be swapped without touching order logic.
- Can vendors have their own staff accounts?
- Yes — owner versus employee is resolved on every action, with fine-grained per-employee permissions. Ajza ships exactly this for multi-branch stores.
- What does a marketplace cost?
- It scales with surfaces and transaction complexity, not with page count. A focused MVP with one buyer surface and a vendor dashboard is a multi-week engagement; a full multi-sided platform with native apps runs across several months. Budgets are discussed openly on the first call and quoted in writing.
- Do you keep working with us after launch?
- An agreed support window is part of every engagement, and longer-term retainers are available. The handover is complete either way — code, infrastructure and deployment are yours.
Written for buyers, not for engineers.
Need a marketplace like this?
Describe the two sides of your market and how money should move between them. I'll come back with an approach, a rough timeline and a ballpark.