TL;DR: Distributors take orders on phone calls and WhatsApp voice notes, keep credit exposure in someone's head, and find stockouts only after a retailer fails to order. Dispatch OS gives each distributor its own retailer ordering platform, blocks orders that breach a credit limit at checkout, and dispatches against live stock.

Built product · Product owner · Live demo (sample data)

Live demo · PRD · BRD · MRD · Spec · Code

The problem

Three failures I kept seeing in distribution operations:

Evidence

These three failures come from what I saw first-hand in B2B distribution and dispatch operations. The product itself has only been run on sample data: a demo distributor with multiple warehouses, a retailer catalogue sold in cases, and credit limits that block checkout when breached. No distributor has used it yet.

How it works

flowchart LR
	A["Retailer orders<br>in cases / MOQ"] --> B{"Within credit limit?"}
	B -->|No| C["Blocked at checkout"]
	B -->|Yes| D{"Stock at a<br>warehouse in radius?"}
	D -->|No| E["SKU flagged out of stock"]
	D -->|Yes| F{"Delivery lane"}
	F --> G["Instant restock<br>from nearest warehouse"]
	F --> H["Scheduled route delivery"]
	G --> I["Payment recorded<br>credit book updated"]
	H --> I

Decisions and trade-offs

  1. Block credit breaches at checkout, not after. Enforcing the limit at order time turns a collections problem into a rule.
  2. Cases and MOQs as the default unit. Retailers reorder in cases, so catalogue, pricing and checkout are built around that.
  3. Two delivery lanes. Instant restock from the nearest warehouse sits beside scheduled route delivery, because urgent and routine orders carry different cost and speed trade-offs.
  4. Multi-warehouse from day one. Each depot or dark store has its own stock and delivery radius under one account.
  5. Record payments, don't process them. Keeps v1 about ordering and credit.

What I cut