The brief was straightforward: a logistics and transport group operating across three countries in the Middle East needed to stop running their 200-vehicle fleet by phone and paper.

The scope was not straightforward: a real-time dispatch dashboard, a driver mobile app in English and Arabic, a route optimisation engine, a vehicle maintenance tracking system, and an integration with an enterprise client's SAP system. All of it, live and in production, within 12 weeks.

This is what it actually took — and what we learned about building logistics software at speed without cutting the corners that break things later.

Why 12 Weeks Was the Real Constraint

The 12-week deadline wasn't arbitrary. The logistics group was pursuing an enterprise contract with a major FMCG client, and that contract required real-time GPS integration with the client's SAP supply chain management system. Without the ERP platform, there was no enterprise contract. The 12-week window was set by the client's procurement timeline.

This is a common pattern in fleet management software projects: the internal operations improvement business case is clear, but the driving urgency is almost always a commercial opportunity that has a deadline attached to it.

The Two Weeks We Spent Before Writing a Line of Code

We sent a senior business analyst and solution architect to Dubai for the first week. They shadowed dispatchers, interviewed drivers, and mapped every operational workflow in detail.

This on-site discovery is not standard for offshore development engagements — most agencies start with a written requirements document and a video call. We don't, because requirements documents for complex operational software are almost always incomplete in ways that only become apparent when you see the actual workflow.

The Dubai visit identified several nuances that wouldn't have been captured remotely. Drivers communicated primarily in Arabic and Hindi — a localisation requirement the initial brief had mentioned but not fully scoped. The dispatch workflow had significant complexity around multi-drop routes that turned out to require a dedicated route optimisation module, not just basic assignment functionality. And the GPS hardware already installed on the vehicles used a proprietary streaming API with specific integration requirements.

We came back from Dubai with a full workflow map, a revised scope, and a three-phase delivery plan: 12-week MVP (dispatch, tracking, proof-of-delivery), phase two (route optimisation and predictive maintenance), phase three (SAP integration). The client committed to all three phases from the outset, with milestone-based payment gates.

What We Built in 12 Weeks

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 to vehicles, see real-time ETAs, and communicate with drivers through an in-app messaging system. Dispatchers went from managing fleet state in their heads to having full visibility on a single screen.

The driver app — built in React Native for both Android and iOS — 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 automatically alerted dispatch and a maintenance coordinator. The app was localised in English and Arabic. A significant engineering investment went into making it reliable on 2G and edge networks, because drivers in remote areas frequently operate in poor cellular coverage zones.

The admin portal gave operations managers their first access to structured fleet data: vehicle utilisation reports, driver performance scorecards, maintenance history, and fuel consumption analytics.

The real-time position tracking used TimescaleDB — a time-series extension to PostgreSQL — for the GPS telemetry data. Standard PostgreSQL would have been significantly slower for the time-windowed queries we needed ("show me the path of vehicle X between 8am and 2pm today"). TimescaleDB's hypertable architecture gave us order-of-magnitude better performance on exactly these queries.

What Happened After the MVP

The route optimisation engine, delivered in phase two, used Google's OR-Tools library to calculate optimised multi-drop routes considering 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 SAP integration, completed in phase three, used SAP's standard IDocs interface to push proof-of-delivery confirmations and order status updates into the enterprise client's supply chain system in real time. This was the deliverable that unlocked the enterprise contract.

The Numbers After Go-Live

The group went live across all three countries simultaneously, 12 weeks after kick-off.

Average time to assign and dispatch an order fell from 8 minutes to under 2 minutes
Fuel costs fell by 22% in the six months following the route optimisation rollout (better than the 15–20% the group had estimated, because the optimisation also surfaced patterns of vehicles idling excessively at certain stops)
The enterprise contract was signed three months after the SAP integration went live

"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." — COO, Confidential Logistics Group, UAE

What Makes Fleet Management ERP Projects Succeed or Fail

The technical stack matters less than people think. What actually determines success is the quality of the pre-build discovery, the localisation investment (a driver app that doesn't work in Arabic will not be adopted), and the discipline to build the core operational workflows first and defer complexity.

The route optimisation engine was always part of the plan, but we deliberately didn't build it in phase one. Optimisation on top of a dispatch process that dispatchers don't trust is worse than no optimisation — it creates a black box that people route around. Building trust in the core system first, then layering optimisation, is the right sequence.

If you're building fleet management, logistics, or operations software and want to talk through the architecture — or if you're in a similar situation to the client here, running a complex operation on phone and paper and needing a path to digital — book a call. We've built these systems across three continents and can give you a realistic assessment in 15 minutes.