Delivery and logistics app development

Three products wearing one name

Delivery work is rarely one app. There is usually a driver app, a dispatch console for the office, and some tracking for the person waiting, and the three have very different requirements. The driver app is the difficult one. It runs all day on a personal phone, in traffic, in bad light, one handed, on a network that comes and goes, and it is used by someone who is paid to deliver parcels rather than to operate software. Everything else on this page follows from taking that seriously.

What is in scope here is the workflow: who is assigned what, what the system records as a job moves, what is captured at the door, and what happens on the days none of it goes to plan. Route optimisation as a mathematical problem, warehouse and stock design, and certification for regulated freight are separate subjects. Our own Aruva Marketplace concept includes a last-mile workspace with routes, drivers and milestone tracking alongside the warehouse and support roles it depends on. It is a concept prototype rather than client work, and a web platform rather than a published driver app.

Roles, permissions and who resolves an exception

Four roles are usually enough to start: a dispatcher who creates and assigns work, a driver who carries it out, a recipient who receives it, and an administrator who configures the system and sees everything. For each, write down what they may see, change, approve and resolve. A driver may record a failed delivery but not decide whether it is re-attempted tomorrow or returned to the depot. A dispatcher may reassign a job but not edit proof that has already been captured. Those rules are what make the system trustworthy as a record afterwards.

Recipients need the least and are the easiest to get wrong. Decide how much they are told, how they are identified and what they can do, because a tracking link that exposes a phone number, an address or a live map of a driver to anyone holding the URL is a privacy problem you created for yourself.

Assignment, acceptance and the job that moved

Model a job as a sequence of events rather than a single status field: created or received, assigned, accepted by the driver, collected, in progress with permitted location updates, completed or failed, then reconciled. Two decisions sit inside that. First, whether drivers accept work or simply receive it, which is a commercial and employment question as much as a design one. Second, what happens when a job the driver is holding has already been reassigned by the office. It needs a version check rather than a race: the app asks the server before acting, and the driver is told plainly that the job has moved rather than delivering a parcel that is no longer theirs.

Live location costs battery, privacy and goodwill

Continuous tracking is requested in nearly every delivery brief and is worth interrogating. Android's documentation on location permissions, read on 18 September 2026, separates foreground access, which covers a feature that shares or receives location once or for a defined period while the app is visible or running a foreground service, from background access, required when a feature constantly shares location or uses geofencing. It also separates approximate access, described as accurate to within about three square kilometres from the platform location providers, from precise access, usually within about fifty metres, and says an app should still work when only approximate location is granted. That is Android-specific guidance on the date we read it, and iOS handles the same question differently.

The consequences are practical. Background updates cost battery on a phone the driver needs all day, so update frequency and whether tracking runs only between collection and delivery are scope decisions with a real cost. Permission can be refused or reduced at any time, so the app needs a documented fallback rather than a broken screen. And location history is personal data about a person at work: agree what is collected, who may see it, how long it is kept and what it may be used for, then tell the drivers. A tracking design the people being tracked consider unreasonable gets defeated, usually by leaving the phone in the van.

One dispatch team, three steps

The table works a fictional dispatch team through three steps of a parcel round on a network that keeps dropping. Roles, policies and responses are assumptions made for illustration, and the last column lists evidence to collect before sign-off.

Proof of delivery is a policy decision before it is a camera

Decide what proof actually means for your business, because the answer changes both the app and the liability. A photograph at the door, a signature on glass, a code given by the recipient, a typed name and a timestamped location are different levels of evidence and intrusion. Then settle the rest of it: whether proof is mandatory or conditional, what happens when it cannot be captured, who may view it afterwards, how long it is kept, and which status change it authorises. Photographs of doorways and signatures are personal data, and keeping them forever because nobody chose a retention period is still a decision.

Nobody home, wrong address, refused parcel

Failure is a normal outcome in delivery and deserves a designed path rather than a text box. Agree a short controlled list of failure reasons, because free text cannot be reported on and cannot drive a rule. For each reason decide what happens next: re-attempt tomorrow, leave with a neighbour where policy allows, return to depot, or hand back to the dispatcher, and decide who may choose. Then stop a job being completed twice, once by a driver whose app finally reconnected and once by a dispatcher who gave up waiting, by giving every completion event an identity and making conflicting events a review task rather than a silent overwrite.

Offline is the normal condition, not the exception

Basements, lifts, industrial estates and rural roads are where deliveries happen. Assume the network is missing and design for it: what the driver can still see, what they can still record, how unsent work is shown so nobody is guessing whether it went, and what the office sees meanwhile. The rule that matters is that the device holds intentions while the server holds the truth, so when a queued event arrives late and contradicts something the office has already done, the system surfaces it for a person instead of choosing quietly.

Name the authoritative system for jobs, addresses, stock and reporting, and the reconciliation rule when more than one is involved. Where drivers, dispatchers and customers each need their own sign-in and their own view, accounts and portals covers that layer, and the office-side tooling a driver app reports into sits with the core systems we build.

What to bring to a scoping conversation

Bring one real day: how many jobs, how they arrive, how they are assigned, who drives, and what they use today. Bring the systems holding orders, addresses, stock and reporting, and whoever administers each. And bring the worst recent failure, because the shape of your exceptions tells us more about the build than your good days.

Mobile app development covers the decisions common to any app, and a scoped enquiry is the quickest route to an honest view of which parts are ready to build and which need confirming first.