The Driver App

What this chapter covers

The driver app is Korido on the driver's phone — a standalone native app built for the person behind the wheel on a multi-day Douala-N'Djamena haul. This chapter describes who it serves, what it helps a driver do (know the mission, capture paperwork, stay notified), the offline-first behavior that keeps it useful across long stretches of weak coverage, and the single rule that defines it: the phone is never the fleet's source of position truth.

Who it is for

The driver app is for the driver. It assumes a working phone and intermittent data, and it is designed to be usable without deep literacy or app fluency: guided choices, large touch targets, and French-first copy. It is a companion to the work, not a dispatch console — planning, corridors, and the vehicle diary all live on the fleet app, which the driver never opens.

The single most important thing to understand about this surface: the truck's hardware tracker is the sole source of position truth, and the phone's GPS is for on-screen display only.

Boundary

Driver phone GPS may help the driver orient or tag a document photo. It is never synced as fleet telemetry and never becomes the position an owner or customer sees.

What the driver sees and does

The app is organized around a small set of tabs, each mapping to one thing a driver needs on the road.

Mission awareness. The missions tab shows the driver's assigned work, and a mission detail screen carries the specifics of the current haul — origin, destination, waypoints, cargo, and schedule. When an owner assigns a mission, a notification row is created for the driver and appears in the in-app center; Expo push delivery is wired through the platform pipeline but currently gated off by worker configuration until rollout. Navigation aids help the driver orient toward the next waypoint; turn-by-turn routing remains the phone's own map, since Korido's job is to say where to go, not to redraw the road.

Capturing paperwork. A corridor run generates documents — customs papers, a signed delivery note, fuel receipts, vehicle and driver papers, a photo of a repair. The documents tab is deliberately simple: four guided capture choices, camera in one tap, and an optional location tag attached to the photo purely as context. Each capture is queued locally and uploaded when the network allows, and a local history lets the driver review what they have sent, with previews that work even offline. When an owner sends a document back for a fix, the request returns here as a "Documents à reprendre" prompt that deep-links to a recapture. The whole capture-to-review lifecycle is the subject of Part 5 — Documents.

Staying notified. The app carries an in-app notification center, with system push treated as a rollout-controlled delivery channel. Notifications are grouped into categories — mission, Route Guard, fuel, documents, and system — so a driver can tell an urgent route-guard alert from a routine acknowledgement. The driver also receives directed requests — such as a system prompt to confirm a pause when a mission looks stopped — which arrive as actionable notifications that deep-link straight to the right screen. The notification mechanics, categories, and preferences are shared with the owner app and detailed in Part 6 — Fleet intelligence.

Offline-first behavior

The corridor has long stretches where a phone has no usable data, so the app is built to keep working when it is offline and to reconcile when it reconnects. Documents are the clearest example.

Every captured photo is copied into the app's own storage before any upload, so a retry survives closing or restarting the app and the driver's history shows a preview even before the file reaches the backend. Uploads retry automatically when connectivity returns. Session credentials are held in secure device storage, and small preferences and flags are kept locally, so the app opens and shows the driver's data without waiting on the network.

The boundaries of this surface

• The phone is display-only for position. The truck's hardware tracker is the sole source of fleet position truth. The driver's phone GPS is used only for on-screen orientation and as an optional context tag on a document photo — it is never synced to the backend and never becomes what an owner or customer sees. This is not a limitation to work around; it is the design.
• Owner-only planning. The driver app does not create or edit missions and has no vehicle diary. Those are owner concerns.
• Document capture is a first pass. Photos are validated lightly for basic quality; deeper checks like blur, glare, or automatic data extraction are future intelligence, not current behavior.
• A standalone app. The driver app runs on its own native release cadence and does not share the web design system — its screens are built for the phone, not ported from the browser.

How it connects

• Part 6 — Fleet intelligence — how notification records, push eligibility, and directed requests are produced and delivered.
• The owner app — the sibling native app that shares the notification stream and its preferences.
• The fleet app — where the missions a driver sees are created and where their documents are reviewed.
• Part 5 — Documents — the full document lifecycle from capture here to owner review and the retake request back.
• Part 2 — Telemetry — why the hardware tracker, not the phone, is the source of position truth.