Delivery dispatch for merchants who run their own drivers

The problem

A merchant selling online has two bad options. Hand fulfilment to a delivery marketplace and give up a cut of every sale along with the customer relationship — or run their own drivers and lose all visibility the moment one leaves the shop.

The second option is cheaper and almost always worse to operate. Nobody can tell a customer where their order is. Nobody knows which location should be fulfilling it. And when a driver arrives at the wrong place, the cost lands on the merchant.

What it does

An order placed on the merchant’s store arrives by webhook, is matched to the right supplier location by SKU, and is dispatched to a driver as a two-leg route — driver to pickup, pickup to customer. Four parties see the same delivery at the same time.

Dispatcher dashboard — assign, monitor, map. An order that matches no location is held here rather than reaching a driver.

Driver app — accept, navigate, stream GPS. Installable, and works on the phone the driver already owns.

Supplier portal — stock toggle and order book, with a WhatsApp alert the moment a leg is assigned.

How it’s built

Postgres with row-level security holds the order; realtime subscriptions keep three separate apps in sync without polling. Serverless functions handle ingest, SKU routing and status write-back. Routing and geocoding run on open map data rather than a metered maps bill.

The ingest layer is deliberately platform-agnostic. One eCommerce platform is connected today, but nothing below the ingest boundary knows or cares which — moving to another is a connector, not a rewrite.

The decision that mattered

The driver and the supplier see the order at the same moment, and their status flows are deliberately independent — the driver sets off for the pickup without waiting for the supplier to mark anything ready. Sequencing them would have been the obvious build, and would have added a wait to every single delivery.

A second one, less obvious: an order whose SKU matches no location fails loudly. It surfaces on the dispatcher’s screen as an exception rather than passing quietly through to a driver with no address to go to.

Outcome

Load tested at 10, 25 and 50 concurrent drivers: 6,650 writes with zero errors, at a steady-state latency of 235–265 ms.

The finding that changed the design was that the ceiling is GPS write volume, not compute. Knowing that early meant building the retention strategy around it instead of discovering it in production.

Running in production with one merchant delivering from several locations across a metro.