Courier software essentials: tracking, proof of delivery, cash on delivery

Tracking starts with custody scans

Start with the events. The map comes later.

Every time a parcel changes hands, the system should write one event: what happened, who did it, where and when. Booked at the counter. Received at the origin terminal. Loaded onto a vehicle. Arrived at the destination terminal. Handed to a rider. Delivered, or failed with a reason. Returned. If a parcel goes missing, that list tells you the last person who held it. A public tracking page then shows the customer a short version of the same list, in plain words, without exposing staff names or internal notes.

Live rider location is a separate decision, and on Android it comes with rules. On Android 11 and higher, the system permission dialog does not offer the "Allow all the time" option; the rider has to turn on background location from a settings page. Google Play also asks apps that use background location to show an in-app disclosure, fill in a declaration in Play Console for one location feature, and record a short video of it. Play's own guidance lists delivery tracking for customers, as opposed to drivers, as a feature that could potentially use foreground location instead.

My rule: track the rider's location only while a job is open, and only if dispatch will act on it. If nobody watches the map, scan events are enough for version one.

Proof of delivery that settles a dispute

A tick box saying "delivered" does not win an argument. This is the checklist I would build into the rider app.

• Who received it: name, and whether it was the addressee, a family member, a guard or reception.
• A photo of the parcel at the door or in the recipient's hand.
• A signature on screen, or a one-time code the customer received by SMS, depending on the value of the shipment.
• The time and the phone's location at the moment of capture, not at the moment of upload.
• For a failed attempt, a reason from a fixed list (no one home, wrong address, refused, customer asked to reschedule) plus a photo of the door.
• Capture that works with no signal, storing the record on the phone and sending it when the connection returns.
• A view in the admin side where support staff can open the proof for any shipment in one click.

A worked cash on delivery reconciliation

Cash on delivery is where courier systems lose money quietly. The amounts below are an illustration I made up to show the method, not figures from any client.

One rider leaves the terminal in the morning with 18 COD parcels, expecting to collect AED 4,250 in total. The rider app records the amount collected on each parcel at the door.

• Delivered: 15 parcels, expected AED 3,600.
• Failed and brought back to the terminal: 3 parcels worth AED 650. Check: 3,600 plus 650 is 4,250.
• Cash counted at the terminal counter in the evening: AED 3,540.
• Difference: AED 60 short. Because amounts are recorded per parcel, the system shows exactly where. One customer paid AED 140 on an AED 200 parcel and the rider entered that at the door.
• The cashier accepts AED 3,540, and the AED 60 sits against that one parcel as an open item for a supervisor to resolve.
• Merchant side: 10 of the delivered parcels belong to one merchant, worth AED 2,400. At an example fee of AED 15 per delivered parcel, the merchant's payout is AED 2,400 minus AED 150, so AED 2,250.
• That payout is released only once the cash has been counted in at the terminal, not when the parcel was marked delivered.

What a courier build involves with me

The closest project I have is my Cargo and Courier ERP case study: a cargo and courier operations platform for shipment handling, terminal operations, dispatch, delivery and tracking. It covers shipment booking, rider workflows, proof of delivery, public tracking, audit trails and operational reporting, built on Next.js, Node.js, Prisma and PostgreSQL. My role was software architecture and product development.

A full courier system like that is custom software with a fixed quote, agreed once the scope is written down. A smaller piece can fit a package. A rider app that talks to a system you already run could sit in Launch ($999) or Growth ($1,699, with its own Node.js and PostgreSQL backend). A rider app plus the admin dashboard to run it is Scale territory ($2,500, up to 50 screens). Barcode scanner or label printer integrations, real-time location streaming and complex payment gateways for merchant payouts are quoted separately. SMS, maps and hosting fees are not included.

Send me your current statuses and how cash comes back to the counter today, even if it is a spreadsheet. That is enough for me to write a scope.