A mid-sized distribution firm in Tangerang came to me with a familiar wish: one app that every driver would use for everything. Six months later, half the features they had paid for were dead weight, and one small feature had quietly become indispensable. This logistics driver app case study is really about a single lesson that keeps repeating in field software.
The features that survived were the ones that gave drivers something back. The features that died were the ones designed in a meeting room by people who had never spent a shift on the road. That gap between head office intent and field reality is where most operational software goes to die.
I want to walk through exactly what worked, what flopped, and the change in how we built that turned the project around.
The Setup
The company ran about 40 drivers doing last-mile and inter-warehouse delivery around Jabodetabek. Before the app, everything moved on paper: printed delivery orders, handwritten signatures, and a WhatsApp group where drivers sent photos when a customer complained. Reconciliation at the end of the day took two admin staff most of an afternoon.
The brief was ambitious. Head office wanted route optimization, live GPS tracking, an in-app chat, digital proof of delivery, fuel logging, and a driver performance dashboard. On paper it looked like a control tower. In practice, we were about to learn which of those things a driver would actually open at 2pm in traffic with a bike engine running.
We shipped the first version with everything. That was the mistake, and it taught us the most.
What Worked
Two features earned their place almost immediately, and both shared one trait: they saved the driver time or saved the driver from blame.
- Proof-of-delivery photos with auto-timestamp and GPS stamp. Drivers adopted this within days without training. Why? It protected them. When a customer later claimed a package never arrived, the driver had a stamped photo instead of an argument. The feature served the person holding the phone, not just head office.
- One-tap status updates (arrived, delivered, failed). Three big buttons, no typing. It replaced the WhatsApp group and cut the end-of-day reconciliation from an afternoon to about 20 minutes. Admin loved it, but crucially, drivers found it faster than typing a message.
The pattern is clear. Both winners reduced friction for the field user. Neither asked the driver to do extra work for someone else's dashboard.
What Flopped
The route optimization feature was the crown jewel in the brief, and it was the biggest flop. Head office imagined the app telling drivers the most efficient sequence of stops. The drivers ignored it entirely.
Here is why, and it is not stubbornness:
- Local knowledge beat the algorithm. Drivers knew which gang was blocked at certain hours, which customer only received goods after lunch, and which alley the truck could not enter. The optimizer did not know any of that and kept suggesting sequences that wasted time.
- It added a step without a payoff. To use it, drivers had to input all stops in the morning, which took 10 minutes they did not have. The reward was a route they often disagreed with.
- No trust, no adoption. After the optimizer sent two drivers down a road closed for a market day, the whole feature lost credibility. Field users forgive nothing that makes them look bad to a customer.
The in-app chat also died quietly. Drivers already had WhatsApp, knew it, and were not going to switch chat apps for work. We had rebuilt something worse than the free tool they already used.
Here is the honest scoreboard from that first release:
| Feature | Head office priority | Actual driver usage |
|---|---|---|
| Proof-of-delivery photos | Medium | Very high |
| One-tap status updates | Low | Very high |
| Route optimization | Highest | Near zero |
| In-app chat | High | Near zero |
| Fuel logging | Medium | Low, sporadic |
The Fix: Build With Drivers, Ship in Weekly Slices
The turnaround was not clever engineering. It was a change in who was in the room. We put two experienced drivers on a short call every Friday and asked one question: what wasted your time this week?
That reset the roadmap. We killed route optimization and the chat. We doubled down on the two winners: faster photo capture, offline support for dead-signal zones, and a simple failed-delivery reason picker that admin actually needed for follow-up.
We also moved to weekly slices instead of big quarterly releases. Each week we shipped one small change, watched the usage numbers, and let the drivers vote with their thumbs. Features that were not opened within two weeks got cut. This is the same discipline I argue for in scoping an MVP that actually ships: build the smallest thing real users will touch, then let evidence drive the next slice.
Within two months, daily active usage among drivers went from roughly 55 percent to over 90 percent. The app got smaller and more used at the same time, which tells you the original scope was the problem, not the technology.
The Takeaway
Field software lives or dies on adoption by the person in the field, not on the ambition of the brief. If a feature does not save the driver time or protect them from blame, they will route around it, and no mandate from head office will change that for long.
If you are commissioning any operational app, apply three rules. Put the actual end user in the design room from day one. Ship in slices small enough to measure adoption week by week. And be willing to kill your favorite feature when the usage data says nobody wants it.
The most expensive line item in that first release was the feature everyone was proudest of. That is the trap. For more on why the people who build systems see these gaps that pure advisors miss, see consultants vs builders. And if you want a technical partner who designs software around the people who actually use it, that is the kind of work I take on through a partnership.