Transport Management App Development

Engineering teams building transport management systems face a recurring set of hard problems: vehicle telemetry at scale, trip state consistency across distributed mobile clients, driver allocation under real-time constraints, and regulatory compliance that varies by market. Scrums.com builds dedicated teams around your transport domain -- engineers who design fleet tracking infrastructure, trip lifecycle state machines, driver-allocation engines, and route optimisation pipelines. Every architecture decision is made to serve operators running fleets, not passengers booking rides.

Vehicle Tracking and Fleet Management Architecture

Fleet visibility depends on a telemetry pipeline built for continuous, high-frequency position data. The core is a vehicle_positions table -- append-only, with columns for vehicle_id, timestamp, latitude, longitude, speed, heading, and odometer reading. Vehicle IoT devices stream over MQTT to a broker, messages fan out via Kafka to a stream processor that writes to vehicle_positions and materialises a vehicle_current_state view for the dispatcher UI. PostGIS handles all spatial queries: nearest available vehicle, geo-fence intersection, and zone-based filtering.

Geo-fences are stored as PostGIS polygon geometries in a geo_fences table. A fence_events table records every ENTER and EXIT event as an append-only log -- no row is ever updated, only inserted -- giving operators a complete audit trail of zone compliance. Vehicle state follows a strict state machine: AVAILABLE -- ASSIGNED -- IN_TRIP -- RETURNING -- MAINTENANCE. Illegal transitions are rejected at the application layer before any database write.

Fleet configuration lives in a fleet_config table covering vehicle capacity, type, permitted zone, and emissions class. Maintenance scheduling uses service_interval_km and last_service_odometer to compute next_service_due_at; work orders are append-only. A compliance_docs table tracks document expiry dates by type -- insurance, roadworthiness certificate, operator licence -- with a pre-expiry alert queue that notifies fleet managers before a vehicle becomes non-compliant.

Trip Lifecycle and Dispatch Engine Architecture

Trip state is the central consistency boundary in any TMS. A trips table holds the canonical state (PENDING -- DRIVER_ASSIGNED -- IN_PROGRESS -- COMPLETED | CANCELLED) and is the only mutable record. Every state transition writes to a trip_events append-only log with trip_id, event_type, actor_id, timestamp, and a metadata JSONB column for transition-specific context. This log is the authoritative source for billing, compliance, and dispute resolution.

The dispatch engine scores candidate drivers using a weighted function over: proximity of current position to the pickup point (PostGIS ST_Distance), vehicle type compatibility with the load, driver availability status (ONLINE only), and hours-driven-today against HOS thresholds. The scoring function is parameterised in a dispatch_config table so operators can adjust weights without a code deployment. Assignment is atomic: driver status transitions to ON_TRIP and trip status transitions to DRIVER_ASSIGNED in the same database transaction.

Route calculation uses a self-hosted OSRM or Valhalla instance. Pre-computed route_legs store sequence, encoded polyline, estimated duration, and distance for each leg. ETA is recalculated at each significant position deviation -- defined as actual position drifting beyond a configurable distance from the planned polyline. Hours of Service compliance is enforced through a driving_time_log and a computed break_required_at field derived from cumulative driving time; duty_status_changes are append-only for tachograph-equivalent audit trails.

Route Optimisation and Multi-Stop Scheduling

Multi-stop transport scheduling is a Vehicle Routing Problem (VRP) variant. Scrums.com teams use OR-Tools with VRPTW (time window) constraints as the default solver. An optimisation_job table captures each run: algorithm, parameters JSON, status (QUEUED -- RUNNING -- COMPLETE -- FAILED), result routes JSON, and elapsed time. Stops carry (earliest_arrival, latest_arrival) windows; the objective function minimises total distance plus a penalty for window violations weighted by service level.

Historical traffic speeds are ingested from a provider feed (TomTom or HERE) into a historical_traffic_speeds table keyed by road segment and time-of-day band. The routing engine uses these to adjust leg duration estimates before solving. schedule_runs represent recurring dispatch windows with a capacity_utilisation metric computed from assigned vs available vehicle-hours. Real-time reoptimisation triggers on: order cancellation, insertion of a high-priority load, or a delay event that pushes a stop outside its delivery window. Reoptimisation results are diffed against the active plan; only affected drivers receive updated route instructions.

Toll and charge reconciliation uses a tolls API integrated into the routing call; route_toll_costs are stored per trip leg for accurate cost attribution. Where operators run electric vehicles, charging_stops are inserted automatically based on battery state projections derived from leg distances and vehicle-specific consumption rates.

Compliance Reporting and System Integrations

Regulatory compliance in transport is data-intensive. For EU operators, tachograph data export files (EC 561/2006) are parsed into structured tachograph_events records per driver, enabling automated HOS violation detection rather than manual review. Emissions reporting builds from a fuel_consumption_log -- litres per leg from OBD-II telemetry or manual entry -- multiplied by fuel-type CO2 coefficients to produce fleet-level emissions reports for sustainability disclosures and Clean Air Zone compliance documentation.

Driver compliance documents are tracked in a driver_docs table (licence, medical certificate, ADR certification where applicable) with expiry-driven alert queues. Vehicle compliance covers insurance, MOT/roadworthiness, and operator licence -- all with pre-expiry notification. The compliance_dashboard view aggregates current status across all vehicles and drivers so fleet managers see the full picture without manual spreadsheet maintenance.

System integrations use outbound webhook events: trip.completed, vehicle.geo_fence_exit, driver.hos_warning, and similar events are delivered to customer endpoints with HMAC-SHA256 signatures and a retry policy with exponential backoff. An ERP connector synchronises trip costs and fuel consumption into accounting systems. The driver mobile SDK (Kotlin for Android, Swift for iOS) handles GPS streaming, trip state transitions, HOS logging, and tachograph mode -- reducing the integration surface for hardware manufacturers and third-party device vendors.