D. Delivery: a Kotlin Multiplatform logistics platform built around verifiable proof of delivery.

Context

The brief was a courier service for high-value goods in Pakistan — mobile phones, laptops, and electronics — where a single disputed parcel can cost more than a month of delivery revenue. The existing way of working was WhatsApp messages, phone calls, and a rider's memory.

What kept breaking

Nobody could prove what condition a device was in when it was collected. Cash collected on delivery was reconciled by hand and never quite matched. Riders were assigned by whoever answered first, not by who was actually closest. Customers called for status updates because there was nothing to look at.

The real requirement

Not "an app that books deliveries." A system where the evidence, the money, and the dispatch decision are all produced by the platform itself — so that the answer to "what happened to my parcel" is a record, not an argument.

Expanding-radius dispatch

A new order starts searching for riders inside a small radius and widens in steps on a scheduled server loop until someone accepts or the radius caps out and an admin is alerted. All loop state lives in the order row and is re-evaluated from scratch on every tick, so a missed notification or a dropped tick can never leave an order stuck in a phantom state.

Evidence pipeline

Pickup video, drop-off video, and a recipient e-signature are captured on-device, compressed before upload rather than after, and written to object storage under a per-order path. Uploads are queued through a background worker so a rider on a weak signal is never blocked from finishing a job.

Money integrity

Fares are computed on the server at order creation, not trusted from the client. Rider earnings are credited by a database trigger with a uniqueness guarantee, so a retried delivery confirmation can never pay twice. Cash owed back to the platform is calculated server-side and always nets out the rider's own commission — so the rider's figure and the admin's figure cannot disagree.

Server-enforced order states

The delivery lifecycle is a state machine enforced in the database, not just in the UI. A modified client cannot skip from "accepted" straight to "delivered" and bypass video capture, and a completed or cancelled order cannot be reopened.

Offline-first rider sync

Every job-progress mutation goes through a local outbox backed by an encrypted on-device database and is drained by a sync engine. A rider in a basement or a dead-zone keeps working; the server catches up when signal returns, and state is reconciled on resume rather than assumed.

Realtime that admits when it is unsure

Live subscriptions are treated as a latency optimisation, never as the only path for anything safety- or money-relevant. Each live screen is paired with a coarser reconciliation fetch on resume and on reconnect, so a dropped socket shows a reconnecting state instead of confidently stale data.