We built an AI-powered delivery driver app over 12 weeks — designed to run on the company's fleet devices (Samsung Galaxy A13 — R2,800 retail price, 4GB RAM, Exynos 850 processor). Intelligent address resolution (weeks 1-5): the AI addressed South Africa's address challenge with a multi-layer approach. Address normalisation AI: when a delivery address was entered, the AI: corrected common misspellings (South African place names are frequently misspelled — "Rondebosch" vs "Rondesbosch", "Constantia" vs "Constantina"), completed partial addresses (inferring suburb and postal code from street name and context — South African postal codes map to specific areas, enabling validation), and flagged potentially invalid addresses (addresses that did not match any known street/suburb combination — routed for manual verification before dispatch rather than discovered at delivery).
Informal settlement location engine: for addresses in informal settlements, the AI used: community-contributed waypoints (a crowd-sourced database of landmarks within settlements — "the blue tuck shop on the corner", "the community hall near the clinic" — mapped to GPS coordinates by community liaison agents), historical delivery data (previous successful deliveries to nearby addresses — the AI identified which GPS coordinates corresponded to successful deliveries in the area and guided new drivers using proven routes), and recipient communication AI (when the delivery was dispatched, the app automatically sent a WhatsApp message to the recipient: "Your delivery is on its way. To help our driver find you, please share your live location" — with a WhatsApp location sharing link. 67% of informal settlement recipients shared their location, enabling direct GPS navigation to their door).
Last-known-good location: for repeat delivery addresses, the app stored the GPS coordinate where the previous delivery was successfully completed — providing precise navigation even when the formal address was imprecise. AI route optimisation (weeks 3-7): the route engine was trained on South African driving data.
South African traffic model: trained on 18 months of the company's own driver GPS data (850 drivers × 18 months = rich traffic pattern data), the model learned: minibus taxi patterns (taxi routes, ranks, and peak-hour congestion — particularly relevant in Cape Town where taxi routes on the N2 and R300 create predictable bottlenecks), load shedding traffic (when traffic signals failed during load shedding, specific intersections became severely congested — the model learned: which intersections were most affected, and how congestion propagated through surrounding roads), time-of-day patterns (South African traffic has distinctive patterns: school run (07:00-08:00 and 14:00-15:00), payday traffic (25th of month and month-end — heavier shopping traffic), and Friday afternoon (significantly heavier than other weekdays)), and safety routing (certain areas and routes were flagged for time-of-day avoidance — the route engine avoided these areas after dark, even if they represented the shortest distance, routing drivers through well-lit, higher-traffic alternatives).
Multi-stop optimisation: the AI optimised delivery sequences across 40-60 stops per driver, considering: delivery windows (scheduled deliveries, priority deliveries), temperature sensitivity (pharmaceutical and grocery cold-chain deliveries prioritised for early delivery), and area clustering (grouping nearby deliveries to minimise driving between deliveries — with special handling for informal settlement clusters where the driver should complete all nearby deliveries in one visit rather than returning multiple times). AI proof of delivery (weeks 5-9): replacing paper-based proof with AI-verified digital proof. Photo proof: the driver photographed the delivered package at the delivery location.
On-device AI verified: package visible in frame (the AI detected whether a package/parcel was present in the photo — rejecting photos of empty doorsteps, the driver's dashboard, or accidental captures), location verification (GPS coordinates at time of photo matched the delivery address within 100 metres — preventing drivers from photographing packages at a different location), timestamp verification (photo metadata confirmed the time matched the delivery window — preventing pre-staged photos), and uniqueness check (the photo was compared against recent photos to detect reuse — preventing a driver from submitting the same photo for multiple deliveries).
Recipient verification: for high-value deliveries or age-restricted items (alcohol, certain medications), the app captured: recipient name (typed by driver or spoken — the AI validated against the order's recipient name), and ID verification for age-restricted items (the driver photographed the recipient's SA ID — on-device AI extracted the date of birth and confirmed the recipient was over 18 — the ID photo was processed locally and not stored, protecting POPIA compliance). All proof-of-delivery data was captured in 15-20 seconds — compared to 45-60 seconds for the previous paper-based process. Offline-first architecture (weeks 6-10): the app was designed for load shedding and coverage gaps. Route and delivery data cached locally: the driver's entire daily route, all delivery addresses, customer contact details, and navigation data downloaded at the start of each shift (typically on depot WiFi — approximately 15MB per day for 50 deliveries including map tiles).
AI models cached on-device: address resolution, photo verification, and route recalculation all ran locally without cloud connectivity. During load shedding: the app continued functioning normally — navigation, delivery processing, proof of delivery capture, and customer WhatsApp notifications all operated from cached data and on-device AI. When connectivity returned, the app synced: completed deliveries, proof of delivery photos, updated ETAs, and any address corrections — using compressed uploads to minimise data consumption.