Logistics Platform Development

Every logistics platform we have been asked to rescue failed in one of four places. It was not the tracking map — the tracking map always works. It failed in the money, the network, the driver's phone, or the paperwork.

COD reconciliation is where logistics companies actually lose money

Cash on delivery is still a large share of Indian ecommerce parcels. Every one of those rupees passes through a delivery executive, a hub cashier, a bank deposit slip and a payout file before it reaches the merchant. At each handoff, the number can change.

The systems that fail here treat COD as a status flag on a shipment. The systems that work treat it as a ledger. Cash owed is created the moment the executive marks the parcel delivered. It stays against that executive until it is deposited. The deposit is matched to a bank statement line. The merchant is paid only from cash that has settled. Every entry is double-sided and cannot be changed — a correction is a new reversing entry, never an edit. That is what lets you answer, at 4pm on a Tuesday, exactly how much cash is in the field, who is holding it and for how long. Without that, losses stay hidden until the quarterly audit, and by then the trail is cold.

Hub-and-spoke is a graph problem, and most software pretends it is a list

A parcel does not go from A to B. It goes from a pickup to a first-mile hub, onto a line-haul trip to a regional sorting centre, to a destination hub, into a delivery route with sixty other parcels, and possibly back again on an RTO. Software that sees a shipment as having only "an origin and a destination" breaks the moment you ask a real question. Which bags are on this trip? What is the bag seal number? Which parcels missed the connection, and what is the new ETA for each?

We treat the bag, the trip, the leg and the scan as main building blocks. A scan is a record that cannot be changed. It holds a place, a time, a device and a person. The shipment's state is worked out from its scans, never stored and edited in place. This costs slightly more to build. It is what makes exception handling possible, and that is the whole job of a logistics control tower.

The driver app is offline-first or it is a liability

The delivery executive's phone will lose signal in a basement warehouse, a lift, a gated society and most of rural India. If the app needs a network to record a delivery, the executive will record it later from memory, or not at all. Then your data is fiction.

So we keep a local database on the phone as the main record. Every action is queued as an entry that cannot be changed. When the phone is back online, it syncs, using clear rules for conflicts. The electronic proof of delivery — signature, photo, OTP, geotag — is captured and stored on the phone. It is uploaded when there is signal, with the time of capture and not the time of upload. That difference has settled more than one payment dispute in our clients' favour.

The paperwork is not optional and it is not simple

An e-way bill is required for most consignments above ₹50,000. Its validity depends on distance. It must be extended before it runs out, and a vehicle stopped with an expired one is held and fined. Part-B must be updated when the vehicle changes. FASTag transactions have to be matched to trip cost, or the fuel and toll budget is a guess. We build these as connections that retry on failure, never repeat a step by mistake, and send an alert when a bill is close to expiry. They are not a screen where somebody in operations has to remember.