How We Built a Driver Dispatch App That Cut Logistics Cost by 34%

Client: A regional transport and logistics company based in the UK Midlands | Sector: Road freight and last-mile delivery | Company size: 60 employees, 40 drivers | Project type: Custom mobile application + dispatcher web dashboard | Timeline: 6 months | Build cost: £52,000

The Problem

The client had been running their dispatch operation on a combination of spreadsheets, WhatsApp groups, and phone calls. As they scaled from 12 to 40 drivers over three years, the system hadn't changed. It had just become noisier. Dispatchers were manually assigning routes each morning, which took 90–120 minutes per day and introduced regular errors. Drivers had no visibility into the schedule until they received a WhatsApp message — which meant delays, missed pickups, and a steady stream of inbound calls from drivers asking questions that should have been answered by the system. The client had received quotes from two UK agencies before approaching ZeeBrains. The lowest quote was £95,000 for an 8–10 month build. Both agencies had proposed native iOS and Android apps.

Discovery Phase: Where the Real Work Happened

We started with a paid discovery phase — three weeks, £6,000 — before touching any code. Discovery involved three things: mapping the current dispatch workflow in detail, interviewing three dispatchers and six drivers about their actual pain points, and reviewing the integration requirements with their existing Transport Management System (TMS). What we found changed the scope significantly. First: five of the twelve planned features were based on what the client thought drivers needed, not what drivers actually needed. The driver-facing app had been specced with a document signing module and a vehicle inspection log — both of which were already covered by a separate compliance tool. Removing those two features reduced scope by approximately 20%. Second: a Flutter cross-platform build would handle every requirement — there was no technical reason for separate native apps. Third: the TMS integration was less complex than originally scoped, as the existing system had a REST API that covered the data we needed. The discovery documentation gave us a precise specification, a clear risk register, and the confidence to quote £52,000 for a 6-month build.

What We Built

Driver Mobile App (iOS and Android, Flutter)

The driver-facing app was built for a single use case: give a driver everything they need for their working day in one screen, with no training required. The app showed the day's route, stop-by-stop, with turn-by-turn navigation integrated via the Google Maps Platform API. Drivers confirmed arrivals and departures with a single tap, which triggered automatic status updates visible to dispatchers in real time. Proof of delivery was captured via phone camera — no separate hardware required. The entire interface was designed for use in a vehicle cab: large tap targets, high contrast, no more than two taps to complete any action. We ran three rounds of driver testing during development.

Dispatcher Web Dashboard

The dispatcher dashboard replaced the spreadsheet-and-WhatsApp system with a live map view of all active drivers, a drag-and-drop route assignment interface, and automated alerts for delays or missed stops. Route optimisation was handled via the Google Maps Routes API, which reduced average route planning time from 90+ minutes per morning to under 20 minutes. Dispatchers could also push schedule changes to drivers in real time, with in-app notifications replacing WhatsApp messages.

Backend and Integrations

The backend was built on Node.js with a PostgreSQL database hosted on AWS. Real-time location updates used WebSockets to avoid polling overhead. The TMS integration was a straightforward REST API connection that kept job records in sync between the two systems without any manual data entry. All user data was processed and stored in AWS UK (London) region. GDPR compliance was built into the data architecture from the start: no driver location data was retained beyond 90 days, and all data access was role-restricted.

Tech Stack

Mobile App: Flutter (iOS + Android) | Web Dashboard: React.js | Backend: Node.js + Express | Database: PostgreSQL (AWS RDS) | Real-Time Layer: WebSockets | Navigation: Google Maps Platform | Route Optimisation: Google Maps Routes API | Hosting: AWS (London region) | CI/CD: GitHub Actions

Timeline

Discovery: 3 weeks → Spec document, risk register, final quote Design (UI/UX): 3 weeks → Wireframes to final screens Mobile App Build: 10 weeks → Driver app (iOS + Android) + QA Dashboard Build: 8 weeks → Dispatcher web dashboard + QA TMS Integration: 2 weeks → REST API connector + data testing UAT + Launch: 3 weeks → Driver testing, training, Go Live Phases 3, 4, and 5 ran concurrently with shared API contracts defined upfront, which is what kept the overall timeline to 6 months.

The Results

The app went live in Q3 of the project year. By the end of Q1 post-launch:

Average dispatch setup time reduced from 92 minutes to 18 minutes per day — a saving of 74 minutes of dispatcher time daily.

Driver inbound call volume dropped by 67%. Drivers had the information they needed in the app, which removed the need to call the office.

On-time delivery rate improved from 81% to 94% — driven primarily by the route optimisation module and real-time delay alerts.

The client calculated that the combination of dispatcher time savings and improved delivery performance represented a direct operational cost reduction of 34%. At a full-year run rate, that efficiency improvement covered the build cost (£52,000) within 14 months. The client initially budgeted £130,000 based on UK agency quotes. The final project cost — discovery, build, and first-year maintenance — was £66,000. The cost saving versus the lowest UK agency quote was £29,000.

What We'd Do Differently

The one area we'd extend on a similar project in future is driver onboarding. We spent less time than we should have on in-app guidance for less tech-confident drivers. We resolved this with a short video walkthrough and a one-page reference card — but building progressive disclosure into the UI from the start would have reduced support calls in the first three weeks post-launch. Real-time route optimisation also has more room to grow. A more sophisticated dispatch logic layer — one that factors in vehicle capacity, driver hours regulations, and customer time windows simultaneously — would deliver further efficiency gains. That's now on the roadmap for phase two.

Why This Project Worked

Three things made this project deliver better results than the client expected. Discovery came first. Without the three-week discovery phase, we would have built twenty features instead of fifteen. The £6,000 discovery investment was the primary reason the build came in at £52,000 instead of £95,000+. The driver interviews changed everything — talking to the actual users revealed that the planned document-signing and vehicle inspection modules were solving problems the drivers didn't have. Removing them saved eight weeks of development time. Cross-platform saved the budget — there was no technical case for two native builds. Flutter delivered identical performance for this use case at significantly lower cost.

Interested in a Similar Project?

If you run a UK business with a manual operations process that should be automated — dispatch, booking, job management, field service, asset tracking — we're happy to look at it. We offer a scoped discovery engagement before any build commitment. See our mobile app development capabilities to understand what we've built and how we work. Or get in touch directly to discuss your project. No pitch, no pressure — just a clear conversation about whether we're the right team for the work.