Osen Express

A delivery company in a cash-on-delivery market is really running two networks at once. One moves parcels: pickup from the merchant, through relay hubs, out for last-mile delivery, and back again when the customer refuses. The other moves money: the driver takes cash at the door, hands it in at a facility, and eventually the merchant gets a payout. The second network is where delivery companies lose money, because the cash sits with people, in transit, across shifts and hubs, and a spreadsheet cannot say with confidence who is holding what right now. Osen models both networks in one system.

A delivery and fulfilment platform for the Algerian market. It covers first-, middle- and last-mile logistics across a multi-hub network, fulfillment of orders from warehoused stock, returns, and the custody and settlement of cash collected on delivery. Third-party systems integrate through partner APIs and webhooks that are wire-compatible with EcoManager and EcoTrack, so existing merchant integrations can point at it without changes on their side.

Merchants ship from it and follow their orders and payouts through a React merchant portal. Operations and back-office staff run dispatch, hub transfers and exceptions from a back-office console. Drivers and facility staff sit at the two ends of the cash-custody chain that the ledger records. Finance staff reconcile that cash and issue batch remittances. Each of the five applications is scoped to one of these roles rather than being one application with hidden menus.

• Order management

  Orders are tracked from creation through pickup, hub transfers, delivery and, where it happens, return — as one record rather than as separate records per leg.

• Multi-hub logistics

  First-, middle- and last-mile movements across a network of facilities, so a parcel that crosses several hubs stays a single tracked object throughout.

• Last-mile dispatch

  Assignment of parcels to drivers for the final leg, including the pickup runs that collect from merchants.

• Fulfillment from stock

  Merchants can hold stock in the network and have orders shipped from it, rather than every order starting with a pickup from the merchant.

• Returns

  Refused and undelivered parcels are routed back through the network as a first-class flow, with the cash position adjusted accordingly.

• COD cash ledger

  Cash collected on delivery is tracked through every custody transfer — driver, facility, merchant settlement — with reconciliation and batch remittances built on the entry history.

• Pricing engine

  Delivery pricing is computed by the system rather than entered per order, covering the different services and destinations the network serves.

• Real-time tracking

  Parcel state is pushed over WebSockets, so a portal or console reflects a movement as it is recorded instead of on refresh.

• Partner APIs and webhooks

  Idempotent APIs and webhooks for third-party integration, wire-compatible with EcoManager and EcoTrack.

NestJS services on PostgreSQL and Redis

Core backend services for order management, last-mile dispatch and COD reconciliation, deployed on GCP. 100+ persisted entities and 130+ API controllers across the platform.

Multi-dimensional order state machine

Pickup, relay, last-mile and return are modelled as four independent sub-states. One customer-facing status is derived from them, so operations retain the full picture while the customer sees a single line.

Append-only cash ledger

Every custody transfer — driver to facility to merchant settlement — is written as a new immutable entry instead of updating a balance. Balances are derived from the entry history, which means they can always be re-derived and audited.

Reconciliation and batch remittances

Reconciliation and merchant payouts are built on top of the ledger entries rather than beside them, so a payout is traceable back to the specific collections it settles.

Idempotent partner surface

Partner APIs and webhooks are idempotent by design and wire-compatible with EcoManager and EcoTrack, so an existing integration can be repointed without changes at the other end.

Real-time tracking and pricing

WebSocket-based tracking for live parcel state, and a pricing engine that computes delivery cost from the shape of the job rather than from manual entry.

Merchant portal and back office

React applications on a shared monorepo design system, so accessible component behaviour is implemented once and reused across the operator-facing surfaces.

1. 01

   A parcel's real state is several states at once. Its pickup leg may be complete, its relay leg in progress, and a return already requested against it. Exposing all of that to a customer is noise; picking one status arbitrarily hides legs that operations needs to see.

   What I did

   Pickup, relay, last-mile and return are modelled as independent sub-states, and the single customer-facing status is derived from them rather than stored alongside them. Operations keeps the full four-dimensional picture, the customer gets one honest line, and the two can never disagree because only one of them is authoritative.

2. 02

   Cash on delivery passes through several people before the merchant is paid. If the system stores a balance and updates it, then a lost update, a retried request or a disputed handover silently creates or destroys money — and there is no record from which to reconstruct what actually happened.

   What I did

   Custody is modelled as an append-only ledger. Every transfer from driver to facility to merchant settlement is a new immutable entry; nothing is ever edited. The balance is a derivation of the entries, so it can be re-derived at any point and a disagreement is a question about which entries exist rather than an unanswerable question about a number. Reconciliation and batch remittances are built on that history.

3. 03

   Third-party couriers and merchant systems retry. In a logistics system, a retried webhook that records a delivery twice, or a duplicated remittance, is a financial error rather than a display glitch.

   What I did

   Partner APIs and webhooks were made idempotent, so a repeated call produces the same state as the first one. Keeping them wire-compatible with EcoManager and EcoTrack meant merchants already integrated with those systems could point at Osen without changing their side, which removed the usual source of integration bugs: two teams building to two slightly different readings of one contract.

• NestJS
• TypeScript
• PostgreSQL
• Redis
• GCP
• WebSockets
• React
• Tailwind CSS
• Untitled UI
• react-aria

This is commercial work, so there is no public repository or demo to link. I am happy to walk through the architecture, the evaluation harness, or any decision on this page in a call.