Respect fixed constraints.
Working hours and breaks are part of the plan, so they shape the suggested day rather than appearing as a note afterwards.
Native iPhone application
Drive Flow
A driver-centred pilot combining daily planning, ordered vehicle handovers and private evidence capture.
Four genuine simulator views · demonstration data. Select a screen to inspect it.
The idea
Plan around the driver’s day.
A vehicle movement is more than a collection and a delivery. A driver has a start location, a finish time, breaks and transfers between jobs. Drive Flow brings those constraints into the planning experience, then carries the selected work into a clear handover sequence.
The pilot uses synthetic jobs and sample estimates. It demonstrates the product and engineering approach, rather than operating a live vehicle logistics service.
How it is built
Native interface, connected data.
- 1
SwiftUI on iPhone
Native screens handle planning, job progress, calendar views and evidence capture.
- 2
Authenticated API access
The app uses Supabase services for accounts and saved state, with sessions held in Keychain.
- 3
Private storage
PostgreSQL policies separate user-owned records; vehicle evidence uses private storage paths.
Swift handles the planning and workflow models. Supabase connects the client to authentication, a PostgreSQL database and photo storage. External navigation and transfer handoffs use existing mapping and booking applications.
Design decisions
Reduce the chance of an ambiguous handover.
Keep custody in order.
Collection and delivery stages follow the movement sequence. Checklists and required photos make the state of a job visible.
Protect against stale saves.
The backend checks ownership and the expected record version before accepting a save, helping avoid one device silently overwriting newer state.
Give estimates a clear label.
Sample jobs, travel times and fares are identified as demonstration values. Identity capture is a prototype and does not verify a person’s identity.
Development & updates
Validate the workflow as it changes.
The project includes core app checks, UI tests for key flows and database checks around private state. Simulator screenshots document the interface, while physical-device checks remain important for camera, navigation and booking handoffs.
Changes need to be checked against the whole journey: planning, reserving, viewing the calendar, collecting, delivering and restoring a session. The planner uses a bounded heuristic; it does not promise a mathematically optimal route.
What this demonstrates
A useful starting point for your project.
The same thinking can be applied to a different industry: understand the real workflow, connect the right systems and give people clear control over what happens next.
Your next project
What could we build for you?
Describe your users, the workflow and the systems it needs to connect. We’ll discuss a useful first version.