Yellow Bus operations rebuild
I brought operations tools from separate systems into the new Admin.
Work context
When Yellow Bus was acquired, student, dispatch, and route work was split across generations of operations tools. Internal staff and academies also used different features and permissions.
I helped assess the early technical debt and migration approach. Starting with login and basic UI, I moved existing features into an operations flow in a React and TypeScript Admin, aligning data contracts and access scope as well as screens.
After preparing login and basic UI, I requested APIs from the backend by feature. I reconciled legacy data shapes with new responses while organizing features used by internal staff and academies.
Decisions and implementation
- 01
Feature-by-feature API integration
Not all operations APIs were ready when authentication and basic UI for the new Admin were in place.
I proposed defining the required endpoints and data shapes feature by feature, then connecting screens in order as APIs became available.
- 02
Legacy data exceptions
The student list had to handle real records with no guardian information or with multiple guardians.
I coordinated the response shape with the backend against the legacy operations screen and defined missing and multiple guardian cases as UI exceptions.
The backend shared a revised response proposal, and I continued the list screen against that contract.
- 03
Trip operations screen
Academy staff needed to inspect and change dispatches and routes by date alongside student boarding status and pickup and drop-off locations.
I connected dispatch lookup, a map of multiple routes, boarding-status and stop changes, and access restrictions in the new operations screen. Monitoring used data polling; route and stop management used Kakao Map.
- 04
Stop search options
If an operator did not know a stop’s exact name, name search alone made it hard to find.
I proposed searching by address or selecting from stops associated with the academy.
Implementation details
The operations screen needed academy, date, time, and dispatch selections to stay consistent between the list and map. I separated fetch state from selection state and connected successful changes to a refetch of the relevant trip data.
- 01Choose conditions
Look up dispatches by academy, date, and time
- 02Inspect map
Show multiple routes for the selected dispatch
- 03Edit trip
Change boarding status and pickup or drop-off stops
- 04Refresh data
Invalidate related query caches
Dependent selection resets
React Context managed selected academy, date, time, dispatch, and map focus. Changing academy reset prior selections; changing date cleared time and route selections. This kept dispatches from prior conditions out of the new selection.
Automatic and manual lookups
The time list used useQuery; dispatches and routes were requested explicitly through useMutation. Route requests were blocked without a selected dispatch or while another lookup was in progress. With one route the map focused on that dispatch; with multiple, it centered on the academy and highlighted the selected route with a Polyline.
Dispatch data refresh
After boarding status or stop changes succeeded, I invalidated the query keys for that dispatch’s details, student schedules, and stop list. Related lookups then refreshed from the server result instead of only changing local display values.
Drag-and-drop rules
When a student’s pickup or drop-off stop was dragged, I checked for the same stop, route direction and departure or arrival constraints, and whether boarding and drop-off order would reverse. Only valid moves reached the change-confirmation dialog.
Verification and results
- API collaboration
After login and basic UI, I requested APIs by feature and coordinated a response proposal with the backend for exception data in the student list.
- Operations screen
I implemented an operations screen with academy dispatch lookup, multiple routes, boarding-status and pickup and drop-off stop changes, and access restrictions. The related changes were merged.
- Follow-up operations features
Bulk registration of student boarding schedules and locations followed. The functions needed for operations in the new Admin were connected in stages.
Rebuilt distributed operations functions into workflows in the new Admin and contributed to initial stabilization.
The focus is on rebuilding workflows and features. I do not claim a completion date for the entire migration or a measured stabilization effect.
Reflections
I first clarified who operated each step and the order of the trip workflow. I carried data exceptions and staff-versus-academy permission differences into the new flow.
Based on career records and implementation evidence. Diagrams reconstruct the work for explanation; private product screens and data are excluded.