How We Built a Fleet Management ERP in 12 Weeks — and Cut Fuel Costs by 22%

A logistics group operating 200+ vehicles across three countries in the Middle East was running their entire fleet on phone calls and paper logs. Dispatch was coordinated by supervisors who knew the routes from memory. Fuel consumption was tracked in notebooks. When a vehicle broke down in the field, someone had to call around to find out where it was.

The company had grown aggressively — from 50 vehicles to over 200 in a few years — and the processes that worked at the smaller scale were becoming a serious operational liability. They were losing an estimated 15–20% of their fuel budget to sub-optimal routing. Three vehicles had broken down in a single month, triggering penalty clauses in customer contracts. And a significant enterprise contract they were pursuing specifically required real-time GPS integration with the client's SAP system — something the current setup simply couldn't provide.

They needed a custom fleet management ERP. They needed it in 12 weeks.

What we found in the first two weeks

We didn't start with code. We started with two weeks on-site in Dubai, shadowing dispatchers, riding along on routes, and interviewing drivers through translators. This wasn't politeness — it was risk management. ERP projects that are designed from requirements documents often fail because they misunderstand the real workflow.

What we found during discovery changed several things we would have assumed from a distance. Drivers communicated primarily in Arabic and Hindi, not English — so the driver app needed full localisation from day one, not as a later phase. Multi-drop routes were significantly more complex than the brief had suggested, with last-minute order additions happening frequently mid-route. And the GPS vendor the company already used had a streaming API that could feed real-time position data directly into our system, which meant we didn't need to deploy new hardware.

We scoped the project into three phases with milestone-based payment gates: dispatch and real-time tracking (12 weeks), route optimisation and predictive maintenance (phase two), and SAP integration for the enterprise contract (phase three). The client committed to all three phases upfront but paid at milestones — the right structure for a build of this size.

What we built

The MVP delivered in 12 weeks comprised three interconnected products.

The dispatch dashboard gave dispatchers a live map view of every vehicle in the fleet — colour-coded by status (available, assigned, in-transit, delayed), with the ability to assign orders, see real-time ETAs, and communicate with drivers through an in-app messaging system. For the first time, a dispatcher could see the entire fleet on a single screen.

The driver app (React Native, Android and iOS, Arabic and English) gave drivers their daily order list, turn-by-turn navigation integrated with Google Maps, digital proof-of-delivery capture (photo, signature, timestamp), and a breakdown reporting flow that instantly alerted dispatch and maintenance. A significant engineering effort went into making the app reliable on 2G and edge networks, since drivers in remote industrial areas were frequently on degraded connections. Pending submissions were queued locally and synced when connectivity restored.

The admin portal gave operations managers their first view of structured fleet data: vehicle utilisation reports, driver performance scorecards, maintenance history, and fuel consumption analytics. Dashboards they'd never had before, built on data the business had always generated but never captured.

Phase two: route optimisation

The route optimisation engine used Google's OR-Tools library to calculate optimised multi-drop routes given vehicle capacity, driver hours limits, customer delivery windows, and historical traffic patterns. When integrated into the dispatch workflow, it reduced average route distances by 18% compared to manually-assigned routes.

The combined effect of real-time visibility (eliminating the idle time that came from dispatchers not knowing where vehicles were) and route optimisation drove the 22% fuel cost reduction the client measured over the six months following rollout. That exceeded their own estimate of 15–20% — the gap came from a pattern the data surfaced that had been completely invisible before: certain vehicles were idling excessively at specific stops, not due to traffic, but due to a loading workflow issue at those locations.

Phase three: the enterprise contract

The SAP integration used SAP's standard IDocs interface to push proof-of-delivery confirmations and order status updates in real time into the enterprise client's supply chain management system. This was the deliverable that unlocked the contract — a deal that represented the group's largest single client and provided strong financial justification for the entire technology investment.

The COO summarised it plainly: "We went from managing a 200-vehicle fleet by phone and paper to having a live dashboard that shows us everything. The ERP paid for itself in fuel savings alone within the first six months."

What this kind of project actually requires

A few things made this engagement work that aren't obvious from the outcome numbers.

The on-site discovery was non-negotiable. Remote requirements gathering would have produced a spec that missed the Arabic/Hindi localisation requirement, the multi-drop complexity, and the opportunity to use the existing GPS hardware's streaming API. Two weeks on the ground saved months of rework.

The milestone structure kept everyone honest. Rather than a fixed-price contract for the full scope (which would have created pressure to cut scope when complexity emerged), each phase was scoped and paid at completion. The client always knew what they were getting and what it cost.

The tech choices prioritised the operational environment, not the engineering portfolio. TimescaleDB for GPS time-series data, Server-Sent Events for the live dispatch dashboard, AsyncStorage for offline queuing in the driver app — each decision was made for operational reasons, not because it was interesting technically.

If you're running a logistics operation on manual processes and know the data infrastructure is missing, our custom software development team has built this class of system before. The full case study is on our fleet management case study page. If you want to talk through what a similar engagement would look like for your operation, book a 15-minute call.