Building a B2B dropshipping marketplace from scratch

Context

DropX is a B2B dropshipping marketplace: suppliers on one side, merchants selling on their own channels on the other. I co-founded it and lead product.

Worth stating plainly rather than leaving to the dates: I built it alongside full-time work — as a business analyst at Atos, then as a product manager at Digitas ME. The spans on my CV overlap because the work did.

DropX has no engineering team. I am its entire product and engineering function — every line of the platform in this account is mine — working alongside an operations team of about five who run it daily. That is the context for everything below, and for the third study on this site, which is about the checks I had to build because there was nobody to review my work.

Egypt is a cash-on-delivery market, which shapes almost every product decision below in ways that are not obvious from a European vantage point.

The challenge

Merchants wanted to sell without holding stock. Suppliers wanted distribution without building a sales operation. Neither side could reach the other, and no merchant working at small scale could assemble the layer between them — nationwide delivery, cash collection and returns — on their own account.

What I built

I own the product end to end: supplier onboarding and KYC, the product data model, the order lifecycle, an internal operations console, BigQuery analytics, and the financial and pricing model.

Two pieces carried the most weight.

Order confirmation over WhatsApp

Cash on delivery has a structural loss: an unconfirmed order that gets refused at the door costs the courier fee regardless. Confirming before dispatch is the control, and doing it by hand does not scale.

I designed and shipped an automated confirmation flow on the WhatsApp Business Cloud API. Median confirmation time fell from ~47 to ~23 hours, and roughly a third of daily confirmations are now fully self-serve.

What I cannot tell you is whether it moved return-to-origin, which is the loss the flow exists to prevent. RTO is instrumented — terminal shipment status, corroborated against the courier’s failed-delivery reason chains — but the flow shipped into a period of rising volume and a change of courier mix, and orders were never randomised into it. The within-period comparison favours the flow; the aggregate moves the other way; neither is causal evidence, so I will not claim the win. Confirmation time is the metric I actually have, and a holdout is what would settle it.

That gap is mine. I instrumented the proxy and shipped the feature without setting up the measurement that would have told me whether it worked.

A settlement path built before it was needed

Every DropX order so far has settled as cash on delivery: the end customer pays the courier, and we reconcile against courier settlement cycles.

The order lifecycle also models a second path. When a merchant has already been paid on their own channel, the order is held in a payment-verification state until they settle directly and upload proof, and is released to fulfilment on review. Without it, DropX ships goods against money it does not hold.

It has never been used. Not one order has needed it.

I built it anyway, and I would again: the point at which you discover you need a counterparty-risk control is the point at which it is already too late to have one. What I would not do is call it a capability we operate. It is a control that is ready, and the manual review step in it is sized for a volume we have not yet seen.

Outcome

• Concept to public launch in January 2026
• ~31K unique orders and EGP 25M+ (~US$500K) GMV in six months
• ~17% month-over-month growth, peaking at ~8K orders/month
• Nationwide cash-on-delivery across all 27 Egyptian governorates via two courier integrations
• ~19K shipments from a 34-supplier, 700+ SKU catalogue

What I’d do differently

Proof-of-payment review is still manual. It was the right call at launch volume — automating a flow before you understand its edge cases builds the wrong thing quickly — but the next step is matching InstaPay references against bank records automatically, and I would start collecting the reference data needed for that earlier than I did.