Fleet Management Software: Streamlining Operations

Fleet operations generate enormous amounts of data: GPS pings, fuel receipts, maintenance logs, driver behaviour events, and route deviations. Most organisations collect this data but can't act on it quickly enough to matter. A well-built fleet management system changes that — not by adding dashboards, but by closing the loop between data and decisions.

What Does a Fleet Management System Actually Do?

The core job is deceptively simple: know where every asset is, what condition it's in, and what it costs to operate. The complexity is in doing that reliably across a mixed fleet, at scale, in real time.

A mature system handles four functional areas:

• Telematics ingestion — OBD-II and CAN bus data from vehicle ECUs, typically over 4G/LTE using protocols like MQTT or AMQP
• Dispatch and routing — job assignment, route optimisation against live traffic, and last-mile sequencing
• Maintenance scheduling — predictive triggers based on mileage, engine hours, or fault codes (SAE J1939 DTCs for heavy vehicles)
• Compliance and reporting — ELD mandates, tachograph rules, permit tracking, and emission zone restrictions

These areas look modular on paper. In production, they are tightly coupled. A vehicle breakdown affects dispatch. A compliance gap affects routing. Treating them as independent services is fine architecturally, but the data contracts between them need to be designed carefully from the start.

The Telematics Layer

Most projects underestimate the telematics layer. Hardware varies wildly. A Teltonika FMB920 behaves differently from a Queclink GV300 even when both claim MQTT support. Message frequency, payload structure, and reconnect behaviour differ. You need a normalisation layer before any business logic touches the data.

We typically build this as a stateless ingestion service in Go or Python, writing raw events to Apache Kafka, and then a separate consumer that normalises and enriches before writing to TimescaleDB. TimescaleDB handles time-series queries far better than Postgres alone for this use case, particularly at 50,000+ events per minute.

Routing and Dispatch

Off-the-shelf routing engines like Vroom or OR-Tools handle the combinatorial optimisation reasonably well for standard vehicle routing problems (VRP). Where they fall short is in fleet-specific constraints: refrigerated vehicles with temperature windows, weight-limited bridges, driver HOS (hours of service) caps, and customer time preferences that aren't hard deadlines.

You can extend these engines, but it requires careful modelling. An alternative is to use Google OR-Tools for the base VRP solve and layer custom constraint validators on top, re-solving affected routes incrementally when conditions change rather than re-running the full optimisation.

How Do You Handle Predictive Maintenance Without Overbuilding?

Predictive maintenance is where most teams either overbuild or give up. The "overbuild" failure mode is training a bespoke ML model before you have enough labelled failure data. The "give up" failure mode is sticking to fixed service intervals and calling it predictive because it's in software.

A pragmatic middle path:

1. Start with rule-based triggers on OBD fault codes and mileage thresholds. This alone reduces unplanned downtime significantly.
2. Accumulate 12 to 18 months of fault-to-failure event data before attempting ML.
3. Once you have data, a gradient boosted model (XGBoost or LightGBM) on tabular sensor data usually outperforms more complex architectures for this problem class.

Condition-based maintenance using vibration sensors or oil quality monitors adds fidelity but also adds hardware cost. For most fleets below 500 vehicles, rule-based triggers with good fault code coverage will get you 80% of the value at 20% of the effort.

Integration with Workshop Systems

The maintenance module is only useful if it talks to your workshop or third-party service provider. This usually means integrating with a CMMS (Computerised Maintenance Management System) like UpKeep or Fiix, or building a lightweight work order module if the fleet is self-maintained.

The integration pattern matters. A webhook-driven approach works well for low-volume fleets. For large fleets with complex approval workflows, an event-driven architecture where maintenance triggers publish to a queue (RabbitMQ or Kafka) and the CMMS subscribes is more resilient.

What's the Right Architecture for a Fleet System at Scale?

Concern	Small fleet (<100 vehicles)	Large fleet (>1,000 vehicles)
Telematics ingestion	Single service, Postgres	Kafka + TimescaleDB or InfluxDB
Routing	OR-Tools, synchronous API	Async job queue, incremental re-solve
Real-time tracking	WebSocket from app server	Redis Pub/Sub or MQTT broker (Mosquitto/EMQX)
Reporting	ORM queries, materialised views	Pre-aggregated pipelines, separate read replica
Auth	JWT, single tenant	Multi-tenant RBAC, tenant isolation at DB level

The shift from small to large isn't just about volume. Multi-tenancy introduces tenant isolation requirements that affect the data model from day one. Retrofitting multi-tenancy onto a single-tenant schema is painful. If there's any chance the system will serve multiple clients or business units, design for it early.

Mobile Clients

Drivers interact with the system through a mobile app. The requirements here are different from the back office: intermittent connectivity, limited screen time, and a need for offline capability.

React Native is a reasonable choice if the team is already JS-heavy. Flutter gives better native performance for map-heavy interfaces. Either way, the offline sync model needs thought. Drivers should be able to accept and complete jobs without a live connection, with the app syncing events when connectivity returns. SQLite with a sync queue is the standard pattern.

Driver Behaviour and Scoring: Useful or Noise?

Driver scoring based on telematics data (harsh braking, rapid acceleration, cornering, idling) is genuinely useful for two things: fuel cost reduction and insurance premium negotiation. Fleets that act on driver coaching programmes report fuel savings of 5–15% and accident rate reductions of up to 30%, depending on the baseline.

Where it becomes noise is when scores are surfaced without context. A harsh braking event on a known black spot is different from one in a car park. Contextualising events against map data (road type, speed limit, known hazard zones) improves signal quality significantly.

The ethical dimension matters too. If scores are used in employment decisions, they need to be explainable, auditable, and compliant with local employment law. Build the audit trail from the start.

Conclusion

A fleet management system is primarily a data engineering problem dressed in domain logic. Get the telematics normalisation right, choose a data store suited to time-series workloads, and be honest about what predictive maintenance requires before you attempt it.

If you're scoping a system now, the most valuable thing you can do is map your data flows before writing a line of code. Understand where events originate, what latency is acceptable, and which integrations are mandatory on day one versus later. That scoping work will save more time than any framework choice.

Sodio has built fleet and logistics platforms across multiple verticals. If you want to talk through your architecture or get a second opinion on a design you're already working on, reach out directly.

---

FAQ

What database is best for storing fleet telematics data? TimescaleDB is a strong default. It extends Postgres with time-series optimisations, so your existing SQL tooling still works. For very high ingest rates (above 100,000 events per minute), InfluxDB or Apache Druid are worth evaluating. The right choice depends on query patterns, not just write volume.

How long does it take to build a fleet management system from scratch? A functional MVP covering live tracking, basic dispatch, and reporting takes 3 to 5 months with a focused team. A production-ready system with predictive maintenance, mobile apps, and multi-tenant support is realistically 9 to 14 months. Timeline depends heavily on hardware integration complexity and how many third-party systems need to connect.

Should we use a SaaS fleet platform or build custom? If your operations are standard, use a SaaS platform. Samsara, Verizon Connect, and Webfleet cover most needs well. Build custom only when you have differentiated workflows, need deep integration with proprietary systems, or are building fleet management as a product itself.

How do we handle GPS data privacy and driver consent? This varies by jurisdiction. In the EU, GDPR applies directly to vehicle location data when it can identify an individual. You need a lawful basis for processing, typically legitimate interest or contract. Inform drivers clearly, limit retention periods, and avoid continuous tracking outside working hours. Build consent workflows and data deletion into the system from the start.

What's the biggest technical mistake teams make when building fleet systems? Treating telematics data as reliable. GPS signals drop, devices reboot mid-journey, and timestamps drift. Build your ingestion layer to expect gaps, duplicates, and out-of-order events. If your business logic assumes clean sequential data, you will get incorrect reports and incorrect alerts in production.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.