Real-time portals for drivers, customers, and bookings
I build web applications that connect drivers, customers, and operations teams: trip updates, live tracking, transport bookings, documents, and reporting. This groups related work across several systems.
Context
Much of my professional work sits between a transport operation and the people using it. Drivers need the next stop and a way to report what happened. Customers need to arrange a transport and follow its progress. Operations teams need to manage changes without maintaining a separate version of the same information.
Problem
These users often work with the same trip or booking, but need different views and actions. A driver may report a delay while someone in the office updates the plan and a customer checks the status. The applications need clear data ownership, appropriate access, and a way to keep those views current.
Approach
My work spans Go services, TypeScript interfaces, API integration, and the state that connects the backend to the browser. I work on complete workflows, from forms and validation to server-side updates and the way a changed record appears to the next person who opens it.
Tools for drivers
The driver applications bring together trip lists, stop details, maps, transport instructions, and progress updates. Drivers can record arrival and completion times, waiting time, notes, and deviations. I work on keeping these actions usable on a phone and returning the information to the operational system behind the trip.
Customer portals
Customer-facing views cover transport tracking, booking history, documents, reporting, and account information. Live maps and status timelines turn operational events into something a customer can follow. The portal also needs to handle access to the right organisation's records and make session or connection problems understandable.
Booking systems
The booking work includes address selection, trip details, recurring bookings, order editing, and the administrative views used to manage them. Related tools include address books, reusable templates, documents, and pricing or reporting screens. These are connected workflows: a saved booking has to remain usable when it reaches planning, the driver, and the customer's history.
Keeping the browser up to date
The systems use live connections and API refreshes where the workflow needs them. In the customer portal, a WebSocket client handles notifications and activity messages, reports connection state, and reconnects after unexpected disconnections. I also work on the surrounding behaviour: what the user sees while waiting, how errors are shown, and how the page recovers when a session has expired.
Outcome
Across these projects, the result is a set of working interfaces for the different people involved in a transport: creating and managing a booking, carrying out the trip, and following its progress. The shared theme is connecting the user-facing task to the backend record, rather than treating the portal as an isolated website.
What I learned
The important details are often small: whether a driver knows an update was saved, whether a customer can distinguish a completed trip from one still in progress, and whether an office user can correct a booking without losing context. Those details shape the API and state handling as much as the visible page design.