Driver Operations from Route to Cash
Intro
The last mile of the Kalapurna supply chain runs on a React Native app built for drivers who are often out of signal. Seventeen screens cover the working day - route map, delivery, proof, failure and reschedule handling, balance collection and expenses - and everything queues locally when the network drops.
The Kalapurna Delivery App is the driver-side companion to the Kalapurna CRM. It is an Expo and React Native application in TypeScript, reading and writing the same Supabase database the back office runs on, so a delivery marked complete in a village is the same record the accounts team sees.
The Background
Delivery status was reaching the office by phone call, and cash collected on the round was reconciled from memory at the end of the day. Neither survived contact with a growing distributor network, and neither produced anything auditable.
The Challenge
Rural delivery routes lose signal for long stretches, so an app that assumed connectivity would have been abandoned in a week. The build treats offline as the normal case: a dedicated sync layer backed by local storage and network detection queues every action taken out of coverage and reconciles it when the connection returns.
The Solution
A driver signs in to a route map, works a delivery list, and closes each stop with a completion, a failure reason or a reschedule. Proof is captured on the device camera, location is stamped from GPS, and QR codes are scanned and generated on the handset. Delivery sheets and invoices are produced as PDFs on the phone and shared or printed directly.
Money is handled in the same pass: balance orders are listed, balance collection is recorded against them, and driver expenses are logged on the round. A performance screen closes the loop for the driver, and every entry lands in the CRM's books without re-keying.
The Solution
- 01An offline-first sync layer backed by local storage and network detection - every action taken outside coverage is queued on the handset and reconciled automatically when signal returns.
- 02A route map and delivery list that give the driver the day in the order it should be worked, rather than a spreadsheet printed that morning.
- 03Every stop closes in one of three explicit ways - completed, failed with a reason, or rescheduled - so exceptions are captured as data instead of arriving later as a phone call.
- 04Proof of delivery captured on the device: camera images, GPS-stamped location, and QR codes both scanned and generated on the handset.
- 05Delivery sheets and invoices generated as PDFs on the phone, then shared or printed directly, including amount-in-words rendering for invoice copies.
- 06Cash handled on the same pass - outstanding balance orders are listed, collection is recorded against them, and driver expenses are logged on the round.
The Results
- 01Delivery status stopped travelling by phone call. A stop closed on the handset is the same record the accounts team sees, with no re-keying in between.
- 02Cash collected on the round became auditable - every collection is recorded against a specific balance order at the moment it is taken.
- 03Drivers keep working through dead zones. Offline is treated as the normal operating condition rather than an error state.
The Achievement
- 17 screens covering the full driver day, from login and route map through to performance review.
- A working offline queue that reconciles automatically, built for routes that lose signal for long stretches.
- On-device PDF generation for delivery sheets and invoices, with direct printing and sharing.
- Camera, GPS and QR capture combined into a single proof-of-delivery step.
- Balance collection and expense capture in the field, posting straight into the CRM books.