2026 · Fleet & logistics management
Flee
From a vehicle on a map to a fleet team’s next decision.
The map is one part of the operation
I’m building Flee to give Nigerian fleet teams a clearer way to run vehicles, drivers and trips, beyond a location on a map. I saw room for a product that connects daily operations with the driver’s experience. Sharing the idea alone prompted an investor to reach out. I own the brand, product architecture and design system, including its components in code, across 2 connected web and mobile experiences.
Early investor interest followed sharing the project. Frontend implemented; backend development is in progress.
- 2 experiences
- Web administration and driver mobile
- 1 active assignment
- One vehicle to one driver, with assignment history
- In development
- Frontend implemented; backend work is in progress
Inside this case study
A trip starts before the vehicle moves
Assign
Connect an available vehicle and driver.
Run the trip
Carry that assignment into the trip and its status.
Respond
Make location events and operational changes understandable.
The useful question comes after “where?”
A map can show where a vehicle is. A fleet team also needs to understand who is responsible for it, which trip it belongs to and whether something requires attention.
I’m building Flee with a colleague and own the brand and product experience. I approached it as a connected operational system: company setup, people and roles, vehicles, drivers, assignments, trips, tracking and reporting.
The vision, and the first signal of interest
My vision for Flee is a connected operational workspace for Nigerian fleet businesses: people, vehicles, assignments, trips and location events working together. I saw an opportunity for a more complete local product, with the web operations team and the driver treated as two sides of the same service.
An investor reached out after I talked about the project, before a full product pitch. That was an early signal of interest in the direction. The next step is to turn that interest and the implemented frontend into a working product that can be evaluated in use.
One assignment rule shapes several screens
One vehicle can have one active driver, and one driver can have one active vehicle. Assignment history must remain available when that relationship changes.
That rule connects vehicle records, driver records, assignment actions and the trip lifecycle. The interface needs to preserve those relationships as users move between modules, rather than make each screen appear independent of the others.
Different responsibilities on either side of a trip
The web experience gives administration and operations teams space to manage vehicles, drivers, assignments and trips. The driver’s mobile experience centres on the assigned vehicle and the next action in the trip.
I used those different responsibilities to guide information hierarchy. Administrative detail belongs where the team can review it; the mobile experience needs to keep the driver’s immediate task clear.
Location is a system of events
Geofencing made the design problem more concrete. An arrival, departure or restricted-area event needs rules behind it, and those rules determine what the interface should communicate.
I explored how changing location data connects to notifications and operational context. My map article below explains the shift from drawing a tracking interface to thinking about system behaviour.
A design system that lives in the code
I built Flee’s component-based design system and implemented its components in code. I translated the Figma foundations, hierarchy and interaction states into reusable interface components, then used those patterns across the operational screens.
That gave me a way to refine a pattern in the working application and carry the same decision into the next screen. I worked alongside my colleague on engineering so the visual design and implementation could develop together.
A brand built alongside the product
I developed Flee’s identity at the same time as its interface. The logo, visual hierarchy and motion belong to the same product direction, extending into the brand applications shown below.
The airport, highway and vehicle mockups are concept applications of the identity. They show how the brand could behave outside the application.
What is built, and what comes next
Flee’s frontend is implemented and backend development is in progress. My work covers product structure, operational interface design, brand identity and reusable components implemented in code across web administration and the driver experience.
Working across design and implementation has let me develop the visual language alongside the behaviour it needs to support. The product and brand material below document that work in progress.
What I own in Flee
- Owned the brand and product design across web administration and the driver mobile experience.
- Defined connected workflows for vehicles, drivers, assignments, trips and tracking.
- Built the component-based design system and implemented reusable interface components in code.
- Worked with a colleague on engineering, carrying design decisions into the application.