A logistics loop for Uganda: One connected delivery

Four focused roles, one logistics loop

A delivery can look like four different products. The customer sees an order. The merchant sees goods that need to be confirmed and prepared. The rider sees a pickup and destination. The operator sees timing, assignments, and exceptions across the operation.

It is tempting to build a separate system for each role. The problem appears when those systems disagree. PikiPiki OS is in active development around a different idea: give every participant a focused experience while keeping all four inside one shared delivery journey.

• The customer needs a clear order status and trustworthy updates.
• The merchant needs confirmation, inventory, and preparation controls.
• The rider needs the current assignment, next stop, route, and completion steps.
• The operator needs a wider view of active work, handoffs, and exceptions.

Make every handoff visible

Many delivery problems happen between screens. An order may be ready, but no rider has accepted it. A rider may arrive, but the merchant does not know which order to release. A delivery may be completed physically, but the customer or operator still sees an earlier state.

A connected loop treats each handoff as product behaviour. Important transitions are recorded, the next responsibility is clear, and missing activity can surface for investigation. That does not eliminate exceptions; it gives the team a safer way to find and resolve them.

Give each role the right view of the same truth

A rider does not need a fleet-wide operations dashboard. A merchant does not need every customer or rider location. Each interface should reveal the information needed for that role and that delivery, while still reflecting the same underlying journey.

An authorised operator needs a wider view to coordinate work and respond to exceptions. The value comes from shared state, not identical screens. Focused experiences can remain simple because the system beneath them keeps the order, preparation, assignment, and completion events connected.

Use maps without exposing more location data than needed

Maps can help a rider navigate an assigned delivery and help an operator understand active work. They also involve sensitive location and customer information. Visibility should therefore be purpose-limited: the rider sees what is needed for the rider’s own assignment, while fleet-level views remain with authorised operations roles.

The product should collect only the location information the workflow genuinely needs, keep access tied to a clear purpose, and avoid presenting precise movement as a public spectacle. A useful map explains the next action; it should not become a reason to expose more data.

Where AI assists—and controlled workflows take over

AI can help interpret a conversational order, summarise what needs attention, or support dispatch reasoning. Over time, it may assist with forecasting or planning. Those capabilities are useful only when the underlying order and delivery states are dependable.

Logistics includes commitments, physical goods, customer information, location, and money. Important actions need validated inputs, authorised state changes, clear records, and human visibility. AI can contribute understanding; the operating workflow remains accountable for what the business actually does.

Build a reusable logistics foundation

CheapCheap provides the first operating context for this approach, while PikiPiki Deliveries provides the service layer and PikiPiki OS is being developed as the shared foundation. This is a learning environment, not a claim that every part of the long-term platform is already complete.

The long-term value is reuse. A new merchant should not require a second definition of delivery or another disconnected dispatch model. The goal is one logistics loop for Uganda that can support several focused experiences, preserve appropriate role boundaries, and keep every participant working toward the same completed journey.