Built a real-time roadside assistance platform with live location tracking, smart dispatch and offline fallback via Twilio for seamless driver support.
Roadside assistance is a time-critical service. When a driver is stranded, the quality of the response depends entirely on how quickly help can be dispatched and how clearly the driver's location can be communicated to the technician. The traditional model - a phone call to a dispatch centre, a verbal description of the location - introduces delays and errors that leave drivers waiting longer than necessary.
Our client wanted to rebuild this experience: a digital-first platform where drivers could request assistance through an app, share their exact location automatically and track the technician's arrival in real time. The platform also needed an offline path for drivers in areas with poor data connectivity.
Backend API (Node.js / Express / Sequelize)
The backend serves both the customer-facing app and the dispatch dashboard. We built it with Node.js and Express, using Sequelize ORM against a PostgreSQL database. Core resources - service requests, technician profiles, dispatch assignments, service history - are managed through REST endpoints with JWT-based authentication.
Service request state management is a defined workflow: open → assigned → en_route → on_site → resolved. Each transition is timestamped and triggers downstream actions: push notifications, Socket.IO events to the driver app and dashboard and pricing calculations on resolution.
Real-time tracking (Mapbox / Socket.IO)
Live location tracking is handled through Socket.IO - the technician's app emits location events on a five-second interval once assigned to a job and the driver's app receives them on a dedicated room scoped to the request ID. We used Mapbox for map rendering on both ends, with route visualisation from the technician's current position to the driver's pinned location.
The map integration required careful handling of location accuracy. Mobile GPS accuracy varies significantly and we applied a light Kalman filter on the server side to smooth erratic location jumps before broadcasting to the driver's view.
Offline fallback (Twilio)
For drivers without sufficient data connectivity to use the app, we integrated Twilio to provide an SMS-based fallback path. A driver can text a specific number with their request, the system parses the message and creates a service request with a manual location entry that dispatch confirms by phone. The same state machine governs the request regardless of how it was created.
Internationalised frontend (React / Material-UI / i18n)
The React frontend was built with Material-UI components and full i18n support. The platform targets multiple regions and the translation infrastructure needed to be in place from the start rather than retrofitted later. We structured the i18n implementation around react-i18next with translation files organised by feature area.
Socket.IO rooms scoped to request IDs kept the real-time traffic lean - each driver only receives location updates for their specific assigned technician, not a broadcast of all technician positions. This mattered for scalability as request volume grew.
The Twilio offline path was designed as a first-class workflow rather than an afterthought. Roadside assistance users are by definition in situations where infrastructure is unreliable. Having a degraded-but-functional path for low-connectivity scenarios was a product decision that shaped the architecture from the beginning.
The platform launched with live location tracking, real-time status updates and the SMS fallback path operational. Driver feedback on location accuracy was positive - the smoothing on the Kalman filter made technician movement on the map feel realistic rather than jumpy. The dispatch dashboard gave coordinators visibility into all active jobs and technician positions on a single map view, reducing average time from request creation to technician assignment.