01
Order placed
An order lands in the New Order stage from a customer or created by the merchant from the menu.
New order→
Case study · Multi-vendor commerce
The orderstops for QC.
A bilingual multi-vendor commerce platform where a quality-control checkpoint sits inside the order lifecycle — a merchant prepares an item, submits it for QC, and a reviewer approves it before it can be packed, picked up and delivered.
What we shipped
QC checkpointBilingual catalogueOrder types5 rolesPayment & deliveryMerchant payouts
01 — The product
A marketplace where a review gates dispatch
Merchants manage a bilingual catalogue and take orders; a quality-control reviewer inspects prepared items against a request before they are packed; drivers collect and deliver; customers approve and pay. Four parties, one lifecycle, with QC in the middle of it.
QC is a request, with a name on it
Every review is a QC request carrying a request initiator and an assigned reviewer, so a passed or failed item is always attributable rather than anonymous.
Bilingual to the field level
Products carry an English and an Arabic name side by side, and the interface reads both ways — built for a market that shops in two scripts.
Order type decides the path
An order is tagged QC, QC & Payment or Delivery & Payment, and that tag decides which checkpoints it must clear before it completes.
02 — The problem
Adding a review step to commerce is not a status flag — it changes who can move an order and when.
A review has to be able to stop the order. If QC is only a label, a prepared item ships anyway. The checkpoint has to actually hold dispatch until a reviewer passes it.
Four parties must not see each other's work. Merchant, reviewer, driver and customer each act on the same order from a different surface, and each needs only their slice of it.
Payment and delivery hang off the outcome. Whether payment is captured and delivery dispatched depends on the QC result, so the money and logistics react to the review.
3
things break if QC is treated as an afterthought.
03 — Goals & challenges
What Q had to get right
The work was making one review step feel native to a whole marketplace — designing the order lifecycle first, then hanging catalogue, payment and payouts off it.
Goals
Design QC into the lifecycle
- Model the order lifecycle first — seven pipeline stages and the order types.
- Make QC a real request with a named initiator and reviewer, that can hold dispatch.
- Build the catalogue bilingually — English and Arabic together, RTL-aware, from the start.
- Close the loop with money — reporting and payouts on the same order data.
Challenges
Why it was hard
- A review has to be able to stop the order, not just label it.
- Four parties act on one order from fenced-off surfaces, each seeing only their slice.
- Payment and delivery must react to the QC outcome, not run ahead of it.
- Bilingual has to be a data shape, both names on the product, not a translation layer.
04 — Built for
Who is Q built for?
One order, 5 roles — each acting on the same lifecycle from a fenced-off surface, with QC in the middle.
Merchant
The merchant
Manages a bilingual catalogue, takes orders and prepares each item, then submits it for review before it can ship.
QC reviewer
The reviewer
Inspects the prepared item in the In-Review queue against its request, and passes or rejects a full order or a single item.
Customer
The customer
Reviews the order detail, accepts or rejects it, and moves to payment and delivery from their own surface.
Driver
The driver
Collects a cleared order once it reaches Ready to Pick, and carries it through delivery to the customer.
Admin
The admin
Reads performance by zone and branch across a date range, and settles merchant earnings through payout listings.
05 — The QC path
How does an order pass through quality control?
02
Merchant prepares
The merchant prepares the item against the order, whether it is a menu product or a custom request.
Preparing→
03
Submitted for QC
The prepared item is submitted for review as a QC request — a full order or an individual item.
QC request→
04
QC reviews
The assigned reviewer inspects the item in the In-Review queue and passes or rejects it against the request.
In-Review→
05
Packed & ready
A passed item is packaged and moves to Ready to Pick; a rejected one goes back rather than forward.
Ready to Pick→
06
Driver collects
A driver picks the cleared order up and carries it through delivery to the customer.
Collected→
07
Paid & completed
Payment settles per the order type and the order closes out as completed, feeding merchant payouts.
Completed✓
keep scrolling — the deal glides left →
06 — QC as an afterthought vs In Q
A checkpoint that can actually hold the order
What changes when review is a real object in the lifecycle, not a label nobody enforces.
✓ In Q
“The order cannot advance until the review passes.”
✕ QC as an afterthought
“Nothing stops it shipping.”
← drag to compare →
In the order flow
QC as an afterthought
In Q
Checking a prepared item
A note in a chat, ticked from memory
A QC request with an initiator and a named reviewer
Holding dispatch
Nothing stops it shipping
The order cannot advance until the review passes
Who reviews what
Whoever is around
The request records the QC reviewer against the item
Bilingual catalogue
One language, transliterated by hand
English and Arabic product names as first-class fields
Order routing
One path for everything
Order type decides QC, payment and delivery steps
Merchant earnings
Reconciled off-platform
Payout listings and details built into the platform
07 — Inside the platform
What does each party actually work in?
The surfaces that carry the platform — the merchant's catalogue and order desk, the QC review, the customer's approval and the back-office reporting.
A bilingual catalogue
Merchant · Manage MenuProducts are managed with English and Arabic names, a featured flag, active status and branch scope — the merchant's storefront back office.
Products, variants and modifiers
Merchant · Add productAdding a product covers package size, item sensitivity and modifier groups, so the catalogue can carry real configurable items.
Menu and custom orders
Merchant · Create orderOrders are built from the menu or as custom requests with their own questions and image uploads, then routed by order type.
The checkpoint itself
QC reviewer · In-ReviewThe In-Review order shows its QC requests — request ID, product, initiator, reviewer and status — the moment the order is held for.
Approve, then pay
CustomerThe customer reviews the order detail, accepts or rejects it and moves to payment and delivery from their own surface.
Zones, branches and payouts
Admin · ReportsReporting filters by zone and branch with a date range, and merchant earnings are tracked through payout listings and details.
The whole argument
Preparation and dispatch, separated by a review.
A named person has to pass the item, and the money and the driver only move once they do — that one gate in the middle of the lifecycle is the platform.
11 — What we shipped
The scope, in one panel
Every number in this panel is delivered scope — what was designed, built and handed over on the multi-vendor commerce build for Multi-vendor commerce. It leaves out traffic, conversion and revenue on purpose: those figures belong to the client, and we don’t publish numbers we cannot stand behind.
7
Order-pipeline stages, New to Completed
5
Roles: merchant, QC, driver, customer, admin
2
Scripts: English & Arabic, field-level
1
Checkpoint that holds dispatch
- Industry
- Multi-vendor commerceFood & custom orders
- Platform
- Web platformBilingual EN / AR
- Roles
- Merchant · QC · DriverCustomer · Admin
- What we did
- Product modellingUX architecture · UI
09 — More of the platform
Across the five surfaces
A wider look at the merchant desk, the QC review, the customer approval and the money.
Submit to QC. The merchant uploads the prepared item and a comment before it goes to review.
Order detail. QC requests, products and the paid total on one order.
Customer approval. Accept or reject the order, then move to payment and delivery.
Merchant payouts. Sales period, payout amount and status, tracked per merchant.
Q platform overview.
08 — Visual design
The look, and why
An operational, dependable system — a decisive green signals a passed review, amber holds an order in-review, coral flags a rejection, and a mono voice carries the request IDs and statuses.
Colour
Passed
#12A575
Deep
#0B7A54
Bright
#2FC896
In review
#E8912A
Rejected
#E0553C
Ink
#0F2018
Typography
The order stops for QC
Order pipeline & requests
A QC request carries a named initiator and reviewer, and holds the order in review.
REQ#123456 · IN-REVIEW · EN / AR
Iconography
10 — Transferable
What does a quality-gated marketplace need to get right?
Six things separate a platform where review is real from one where it is a label nobody enforces. They hold for any quality-gated commerce.
01
A checkpoint that can hold the order
If a review cannot stop dispatch, it is decoration — the gate has to actually block the next step.
02
A name on every review
A QC request needs its initiator and its reviewer recorded, so a pass or a fail is attributable later.
03
Order type as a router
Not every order needs every step, so the type has to decide which checkpoints and which payment path apply.
04
Separate surfaces for separate parties
Merchant, reviewer, driver and customer act on one order from four fenced-off views.
05
Bilingual as a data shape
When a market shops in two scripts, both names belong on the product, not bolted on afterwards.
06
Payouts inside the platform
If merchant earnings are reconciled off-platform, the order data and the money drift apart.
FAQ
Building a quality-controlled commerce platform
What makes Q different from an ordinary marketplace?
The quality-control checkpoint. On most platforms an order moves from prepared to shipped in one step; on Q a reviewer has to pass the prepared item first. That review is a real object — a QC request with a named initiator and a named reviewer — and it holds dispatch until it is cleared. Everything else, from the bilingual catalogue to payouts, is built around that one gate.
Can different orders follow different paths?
Yes. Each order is tagged with a type — QC, QC & Payment or Delivery & Payment among them — and the type decides which checkpoints and which payment and delivery steps it must clear before it completes. A custom item that needs inspection and a simple menu order do not have to travel the same route.
Does the platform support Arabic as well as English?
It is bilingual by design. Products carry both an English and an Arabic name as first-class fields, and the interface is built to read right-to-left as well as left-to-right, so it suits a market that shops in both scripts rather than treating one as a translation of the other.
How long does it take to build a platform like this?
A multi-vendor platform with a real review checkpoint, five roles, a configurable catalogue, delivery, payment and payouts is a multi-month programme rather than a few weeks. What moves the date most is how strict the checkpoint has to be and how many order paths it must support. Shanti Infosoft scopes it on a short call and returns a fixed quote.
Let's build
Building a quality-gated marketplace?
Tell us how your business actually works and we'll tell you honestly what it takes to build — the checkpoint, the roles, the payouts. No deck, no pitch.