E-Mart

E-Mart is one of the larger business-to-business electronics marketplaces in Egypt. Vendors list and sell on it, and E-Mart holds its own stock and sells too, so first-party and third-party inventory sit on the same catalogue and compete for the same buyer. Its customers are businesses rather than consumers, which changes what an order is: larger, less impulsive, and placed by somebody purchasing on behalf of an organisation rather than for themselves. Five surfaces carry it. Buyers get a web storefront and a mobile application, vendors get a dashboard and a mobile application of their own, and the platform operators get an administration dashboard behind all of them.

A marketplace that also sells is in a position most commerce systems never have to model: the operator is a competitor. The same electronics line can be offered by E-Mart and by a vendor at the same moment, and the platform resolves that by refusing to resolve it. There is no buy box. Both listings stand and the buyer picks between them, which is the one answer to operator-as-competitor that cannot be accused of favouring anybody, because no ranking rule exists to favour anybody with. Stock is the other half of it. A marketplace does not own most of what it sells, so it is quoting availability and delivery on inventory somebody else controls and updates on their own schedule, and every vendor who is slow, wrong or offline becomes the platform problem at the moment a buyer tries to pay. Business buying sharpens both: orders are larger, so an oversell costs more than an apology, and the buyer is an organisation whose purchasing does not resemble a person buying a phone.

One catalogue, two kinds of seller who are never merged into a single offer, and five surfaces onto them. Buyers browse and order through a Next.js storefront or a Flutter application. Vendors run their side from a dashboard and, less usually, from a mobile application of their own, which says something about the market being served: an electronics vendor here manages stock and orders from a phone rather than from a desk, so the vendor experience had to be built for that rather than treated as a back-office afterthought. The administration dashboard sits behind both and runs the platform itself, covering vendors, catalogue, orders and the rules the other two audiences are subject to. Checkout settles two ways, because business buyers do not all pay like consumers: by card through Paymob, or on bank transfer and trade credit against an invoice, which is how a great deal of Egyptian B2B actually moves. Delivery is E-Mart’s own rather than a courier integration, so the platform controls the last mile on its own stock and on everything a vendor sells through it. Underneath, the commerce spine is the ordinary one, product to cart to checkout to payment to fulfilment to order, and the difficulty is not the spine but that the inventory along it belongs to several parties at once.

A Laravel 10 backend on Octane over MySQL, with Redis in front of the reads that repeat, deployed to an Amazon EKS cluster on AWS. Five clients reach it, two for buyers, two for vendors and one for operators, built with Next.js and TypeScript on the web and Flutter and Dart on mobile. Behind the API the catalogue is the interesting half, because it holds first-party and vendor stock in the same place and has to keep them distinguishable while presenting them as one shelf. Orders sit beside it and reach outward once, to Paymob for the card half of settlement, while the other half never leaves the building: bank transfer and trade credit are reconciled against invoices rather than cleared by a gateway. Fulfilment does not leave the building either, because delivery is run in-house. Firebase carries push to both mobile applications. What is not recorded is how vendor stock is kept current, which is the one genuinely open question left in the system.

• The operator is also a seller, and the system answers that by declining to arbitrate. There is no buy box: when E-Mart and a vendor both list the same line, both listings stand and the buyer chooses. That is a real architectural position rather than a missing feature, because the moment a platform picks a winner it needs a rule, and any rule written by a party to the outcome is open to the accusation that it was written to win. Refusing the mechanism removes the accusation with it. The cost lands on the buyer, who now has to compare instead of being told, and on the catalogue, which has to make two offers of the same thing legible rather than tidy them into one.
• A marketplace quotes availability on stock it does not own. The platform promises a buyer that something can be delivered, on the word of a vendor who updates their own inventory on their own schedule and may be slow, wrong or offline. Every answer to that is a trade: trust the vendor and oversell, hold stock centrally and annoy them, or reconcile continuously and pay for it. The choice is invisible to buyers right up until it fails, and then it is the platform they blame rather than the vendor.
• Money moves two ways here and only one of them is a checkout. Card payments clear through Paymob in the ordinary way; the rest arrives as bank transfer or trade credit against an invoice, on terms, days or weeks after the goods. That means an order can be complete, delivered and unpaid at the same time without anything being wrong, so the order lifecycle cannot treat payment as the event that unlocks fulfilment. Consumer commerce almost never has to model that, and B2B cannot avoid it.
• Business orders raise the cost of every inventory mistake. A consumer oversell is an apology and a refund; a business oversell is a purchase order that cannot be fulfilled, against a company that was buying to a schedule. Tolerance for the usual commerce shortcuts drops accordingly, and the checkout reservation question stops being a neat trade-off and starts being about the standing of the platform with its buyers.
• A vendor mobile application is a statement about the market rather than a feature. It says vendors are not sitting at desks, so the operational surface of the business has to work on a phone, and everything a vendor does in a hurry happens there: accepting an order, correcting stock, answering a buyer. Building it as a first-class surface rather than a cut-down dashboard is the difference between a marketplace vendors use and one they log into once a day.
• Five surfaces over one API is really three audiences with different relationships to the same records, and the vendor is the awkward one. A vendor may see their own products, their own orders and their own buyers, and none of anybody else, on a platform whose operator sees all of it and also competes with them. That is the boundary that has to hold, and it has to hold across two vendor surfaces rather than one.

• First-party and vendor stock on one catalogue, with the platform competing against the vendors it hosts and deliberately declining to rank them
• Two settlement paths, where an order can be delivered and unpaid at once without anything being wrong
• Quoting availability and delivery on inventory the platform neither owns nor controls
• Business order sizes, where an oversell is a broken purchase order rather than a refunded basket
• A vendor boundary that must hold across two vendor surfaces, against an operator who can see everything
• Five clients and three audiences over one API

• Paymob: card settlement at checkout, alongside bank transfer and trade credit that clear against invoices rather than through a gateway
• Firebase: push notification delivery to the buyer and vendor applications

• Laravel 10
• Laravel Octane
• Paymob
• MySQL
• Redis
• Next.js
• TypeScript
• Flutter
• Dart
• Firebase
• AWS
• Amazon EKS
• Docker