FealDeal
Turant Logistics
Cutting order-to-dispatch by 62% for a 400-truck 3PL
A fleet, ePOD and route-planning platform that works offline first, for drivers on roads with poor signal. The two ready-made TMS products they tried before needed a live connection at the moment of delivery.
- Client
- Turant Logistics
- Industry
- Logistics & Supply Chain
- Location
- Gurugram, India
- Duration
- 22 weeks
- Published
- Nov 2022
- Updated
- Oct 2026
62% faster
Faster order-to-dispatch on the ops floor
91% shorter
Shorter POD-to-invoice cycle (8.4 days to 19 hours)
18% lower
Fewer empty-run kilometres in the first full quarter
3.4M/day
GPS pings ingested daily, off the transactional database
01
The challenge
Turant Logistics moves about 1,100 consignments a day across nine hubs. Its fleet has about 400 trucks, a third owned and the rest from vendors. When we met them, the dispatch desk ran on three WhatsApp groups and a shared Excel file. One supervisor in Gurugram owned the file, and everybody else took screenshots of it.
What was actually broken
- Nobody knew where anything was. To find a vehicle, they called the driver. The ops floor had a wall of phones and a whiteboard. When a customer asked "where is my load", the answer was a promise to call back.
- Paper PODs were eating the cash cycle. The signed delivery challan came back to the hub on the driver's dashboard. It was then sent by courier to Gurugram and typed in by hand. Median time from delivery to invoice was 8.4 days. For a business that gives 30-day credit, that is 8.4 days of cash lost on every single load.
- Route planning was folklore. Runs with many drops were planned from memory by whichever supervisor was on shift. Nobody could tell us what an empty-run kilometre cost, because nobody was measuring empty runs.
- Disputes were unwinnable. There was no time stamp, no location tag and no photo. So a "short delivery" claim was the receiver's word against the driver's. Every quarter they gave up a large part of their income instead of fighting.
The hardest problem was the phone signal. It had already defeated the two ready-made TMS products they tried. Many of their long-distance runs pass through areas where a phone has no usable data for hours. Both products they tested needed a live connection at the moment of delivery. Drivers did what drivers always do. They stopped using the app and went back to paper. The test was called a failure of "driver adoption". It was not. It was a failure of design.
02
What we built
We built three things that had to work together: a driver app that works offline first, a route planner, and a vehicle-tracking data flow that would not break. Each one rested on a choice that we want to explain clearly.
Offline-first, not offline-tolerant
The driver app (Flutter, single codebase for a fleet running everything from a 2019 Redmi upward) treats the internet as optional. Every action is saved first in a local SQLite queue on the phone, and the phone confirms it at once. The actions are arrival, start of unloading, ePOD capture and problems. A background job then sends them, and waits longer after each failed try. The driver never sees a spinner and never sees "no internet".
This design needs two things that most teams skip. First, every mutation carries a client-generated idempotency key, because a retry over a weak link will send the same thing twice. With 400 trucks, this is not a risk. It is certain. Second, consignment status is a server-authoritative state machine, so an old offline event that arrives an hour late cannot move a delivered load back to "in transit". Late events are applied only if they are allowed changes. The rest go to the ops team to check, which turns out to be about 40 rows a week.
ePOD is a photo with a location tag plus a signature on the screen. The phone makes it small as WebP (~120 KB) before it joins the upload queue, because it has to work even on a slow 2G connection.
We did not write our own route optimiser
Planning runs with many drops, vehicle limits and delivery time slots is a capacitated VRP with time windows. It is NP-hard, which means very hard, but it is a solved problem. Writing our own simple method would have cost us two months and given worse routes than a proven solver gives in twelve seconds. We set up Google OR-Tools in a small Python service. Laravel calls it through its own queue with a strict limit of 20 seconds to solve, and we save the plan. Laravel runs the business rules, and the solver is just one function.
Telemetry that does not poison the transactional database
400 trucks sending a ping every 10 seconds makes ~3.4M rows a day. We kept those out of the main MySQL database completely. The pings go to a store split by day. Redis holds only the last known position of each vehicle. The live ops map gets updates through Server-Sent Events. Constant checking would have made every ops browser hit the API every three seconds. Reports run from a copy of the database, so a regional manager's month-end export cannot slow down a dispatch.
03
The outcome
The app went to two hubs first and ran there for five weeks. Then it reached the other seven hubs over a month. Drivers were trained in Hindi by their own hub supervisors, not by us. This mattered more than any feature we built.
Where the numbers landed
- Order-to-dispatch fell 62%. The dispatch desk is no longer a wall of phones. Loads are now given out based on live truck availability. The supervisor's job changed from finding trucks to approving special cases.
- The POD-to-invoice cycle collapsed from 8.4 days to under 19 hours — a 91% reduction. The ePOD reaches the server the moment the driver gets signal. Invoicing is a job that starts by itself when the POD arrives. The finance team did not get faster. The information got faster.
- Empty-run kilometres dropped 18% in the first full quarter. This came straight from the OR-Tools route order and return-load suggestions. This saving paid for the project.
- 3.4M GPS pings a day are ingested without the ops database even noticing. The live map updates in under a second for the full fleet, on one small server.
The parts we care about more
Crash-free sessions on the driver app are at 99.6%. The number we really watch is this: the offline queue has never lost a POD. Not one, in over 300,000 deliveries. Short-delivery disputes are now settled by opening a photo with a location tag and a time stamp. This ended the losses almost overnight. It is the result the CFO talks about most.
The system has since taken on a fourth region and a 40% bigger fleet with no change to its design and no rebuild. That is the only real test of whether our first choices were right.
Under the hood
How it's built.
Technology
- Laravel
- MySQL 8
- Redis
- Laravel Horizon
- Flutter
- SQLite (Drift)
- Google OR-Tools
- Python / FastAPI
- Mapbox GL
- Server-Sent Events
- AWS
- Docker
Services used
- Custom Software Development
- Mobile App Development
- Cloud & DevOps
- API Integration
- UI/UX Design
The last two vendors blamed our drivers when the pilot failed. PRS spent a week riding in the trucks and came back saying the problem was their software, not our people. That was the moment we knew.
