Skip to main content
    All case studies
    BlueprintLast-mile & courier companies

    Last-Mile Delivery App for Drivers & Dispatch

    An offline-first driver app with proof of delivery, live ETA links for recipients, and a dispatch dashboard for route changes and returns.

    An example of how we'd build this for a company in this niche: the plan, the architecture and the targets we'd start from. Not a specific client's story.

    Target
    –30%
    parcel-status calls and emails to support within six months of launch
    Target
    99%
    of completed stops with photo, signature or scan proof, from the first month
    Target
    –15%
    failed first-attempt deliveries within six months of launch
    The situation

    Who this is for

    Imagine a regional courier handling 5,000–15,000 stops a day with a mix of employed and subcontracted drivers, many on their own phones. Drivers juggle shipper scanner apps, paper manifests and calls to dispatch, while recipients ring support to ask where their parcel is. The goal is one driver app and dispatch platform that works offline, proves every delivery and gives recipients an honest ETA.

    The hard part

    What makes it hard

    • Signal drops in underground car parks, rural lanes and apartment stairwells, so every stop has to complete offline and sync later in the right order.
    • Delivery disputes come down to evidence, and a blurry photo or a scribble without time and location won't settle a claim.
    • Subcontracted drivers use their own phones and change often, so onboarding has to take minutes and access has to end the day they leave.
    • Each shipper has its own rules on safe places, neighbours, ID checks and reattempts, and a vague 'not home' doesn't tell them what to do next.
    • Dispatchers move stops between vans all day, and each change has to reach the driver without scrambling their sequence.
    The product

    What we'd build

    Offline-first driver app

    Route, stops and parcel lists stored on the device, scanning with the phone camera or a rugged handheld's built-in scanner, and every action queued until the connection returns.

    Proof of delivery

    Photo, signature, barcode scan, PIN or ID check, depending on the shipper's rules for that parcel, each stamped with time and location.

    Failed delivery & safe-place rules

    Structured failure reasons such as no access, refused, damaged or address not found, with photo evidence and per-shipper rules for neighbours, safe places and reattempts.

    Live ETA links

    Recipients get a tracking link with a time window that narrows as the van gets closer, and can leave instructions or pick a safe place before it arrives.

    Dispatcher dashboard

    A live map of vans and stop progress, drag-and-drop reassignment, and exceptions shown first: late routes, failed stops and parcels still on board.

    Returns & subcontractors

    Collections and returns scanned in the same flow, and subcontractor onboarding with document checks, vehicle details and per-stop settlement reports.

    Under the hood

    Architecture

    From the people who use it down to the hardware and third-party systems it talks to.

    1. Apps
      • Driver app (Android & iOS)
      • Dispatcher dashboard
      • Recipient tracking page
      • Subcontractor portal
    2. Platform
      • Routes, stops & parcel events
      • Offline sync & conflict handling
      • ETA & notification service
      • Settlement reports
    3. Integrations
      • Shipper systems (API, EDI or files)
      • Route optimisation engine
      • SMS & email gateway
      • Accounting & payroll export
    4. In the field
      • Driver phones & rugged scanners
      • Vehicle GPS / telematics
      • Depot scan points
    The plan

    Delivery plan

    The same four phases as every project we run - see how we work.

    1. Weeks 1–2

      Discovery

      Ride along on a few routes, map each shipper's proof-of-delivery and failure rules, and collect the manifest and label formats you receive today.

    2. Weeks 3–5

      Design & architecture

      Offline sync model, driver flows tested one-handed in daylight and poor signal, and the integration plan for shippers and route optimisation.

    3. Weeks 6–18

      Build

      Driver app and dispatcher dashboard built side by side, with a pilot depot running real routes from around week 12 and the old process kept as a fallback.

    4. Weeks 19–20

      Launch & handover

      Depot-by-depot roll-out with short driver onboarding, monitoring of sync errors, and handover of code, infrastructure and runbooks.

    The team

    • Product-minded tech lead
    • Mobile engineers (Flutter)
    • Backend engineers
    • Frontend engineer
    • UX/UI designer
    • QA engineer

    Compliance & security

    • Tracking driver location is a form of employee monitoring: under GDPR it should run only during active routes, with clear notice, and works-council consultation where local law requires it.
    • Recipient names, addresses and doorstep photos are kept only as long as claims need them, and photo guidance steers drivers away from capturing people.
    • ID checks for age-restricted parcels record that a check happened, not a copy of the document, unless a shipper contract requires more.
    • Road-traffic rules restrict phone use while driving, so the app hides everything but navigation while the vehicle is moving.

    Tech stack

    • Flutter
    • Kotlin (scanner integration)
    • SQLite
    • TypeScript
    • NestJS
    • PostgreSQL + PostGIS
    • Redis
    • React
    • WebSockets

    Questions we usually get

    Can subcontracted drivers use their own phones?

    Yes. The app runs on ordinary Android phones and iPhones and scans with the camera; onboarding takes a link and a document check, and access ends with the contract. Employed drivers can run the same app on rugged handhelds with built-in scanners.

    Do you replace our route optimisation?

    Not necessarily. If you already use a route optimisation engine, we'd integrate it; if you don't, we'd plug in an established one rather than build our own. The value we add is in what happens after the plan: changes during the day, the driver's reality and the proof.

    Our shippers all send data differently. How do you handle that?

    Each shipper gets its own adapter (API, EDI or scheduled files) that maps their labels, service levels and proof-of-delivery rules into one internal model. Adding a shipper then means one adapter and a rules profile, not a change to the driver app.

    Real client work

    Building something like this?

    30 minutes with the engineers who'd build it. We'll test this plan against your situation: scope, integrations and budget.