Developing a mobile app for a courier service: bottlenecks
Courier delivery breaks not at the "deliver" stage, but at the junction between dispatcher and courier. Addresses are distributed manually — via spreadsheet or chat, and every route change requires a call. While dispatcher explains entrance, next point waits, and delivery window shifts.
Second bottleneck — statuses. Courier closes order, but with weak network mark doesn't reach server and is lost: order hangs "in transit", client calls support, operator finds out actual state by phone.
The more points in shift, the higher share of such discrepancies and less time remains for delivery itself.
Third — feedback. Dispatcher doesn't see real position of couriers and distributes orders from memory, not by load: one overloaded, another idle, and courier order accounting is kept in two places at once.
Therefore developing a mobile app for courier service is not "a beautiful screen with list of addresses", but restructuring data flow between dispatcher, courier and client.
Courier app takes over accepting and confirming orders, local queue of changes during no network, automatic status transmission and route hints: courier delivery automation removes manual calls and manual address distribution. Below we analyze how this is covered.
What a courier service app provides: measurable effect
Order distribution stops being manual work of dispatcher. Request comes from accounting system, app selects courier by zone, current load and remaining shift — route of 10-15 addresses assembled in seconds instead of ten-minute call-arounds.
Dispatcher connects only to exceptions: address out of zone, cancellation, delivery window reschedule.
Reduction of manual calls rests on status model. Transitions — accepted, picked up, in transit, delivered — are recorded in app and immediately visible to client on tracking map, with notification on status change.
Most orders go without a call, and voice clarifications remain for non-standard cases: address change, refusal, re-delivery.
Courier work without connection is a separate requirement, not a trifle.
App writes statuses, confirmation photos and coordinates to local queue with idempotency keys; when network appears it goes to server in one packet, and conflicts are resolved by event time, not by order of arrival. Maps are cached in advance: route is built on OpenStreetMap and doesn't depend on constant channel.
What is visible in metrics after transition:
- route assembly — seconds instead of minutes, distribution without human involvement;
- share of orders without a dispatcher call grows from single digits to majority;
- downtime at unloading falls: courier sees order of addresses and delivery windows, rather than clarifying them by voice;
- a class of failures goes away — lost delivery marks and double assignments for one order.
Effect of delivery automation is made of these numbers, and each is verifiable by logs and reports on customer side.
Ready solution, customization or development from scratch
Three approaches differ not in scope of work, but in who owns the code and how much unique logic will have to be attached to it.
Before choosing, it is worth honestly breaking down courier app into standard — order statuses, route, delivery confirmation, payment acceptance — and into what is truly yours.
| Approach | When suitable | Limitations |
|---|---|---|
| Ready delivery solution | Processes are standard, need to quickly launch routes and statuses in your territory | Logic is sewn into someone else's scenarios, changes only through settings; part of updates and data depends on platform vendor |
| Customization of courier app | Base already runs routes, but need own order distribution rules and integration with accounting system | Architectural decisions of platform are inherited; changes affect its core, timelines depend on openness of owner's interfaces |
| Development from scratch | Non-standard logic — tariffs, zones, multiple warehouses, courier work without stable connection | Longer to first working release and subsequently need own team that updates app following platforms |
Choice of approach is determined by share of non-standard logic and requirements for code control.
If unique scenarios are less than a third, it is more reasonable to take ready base and customize it; if more — from scratch, otherwise every change will run into someone else's architectural decisions.
How implementation proceeds: stages of engineering work
We start not with code, but with how dispatch is organized today: who distributes orders and by what criteria, which order statuses are real, and which live only in dispatcher's head. Output — process diagram and list of places where app removes manual work rather than adds it.
- Survey of dispatch processes. We analyze order distribution, work with refusals and reschedules, shift responsibility zones. We record where orders are lost and how much time manual calls consume.
- Status model and roles. Unified order statuses from acceptance to handover, rights of courier, dispatcher and warehouse — one source of truth for all participants.
- Courier app setup. Route sheet for shift, handover confirmation, photo capture, recipient signature. Marks accumulate on device and go to system when connection appears.
- Integration with accounting system. Two-way exchange of orders and statuses so dispatcher doesn't work in two windows. We check repeated synchronization separately — duplicates and lost orders are unacceptable.
- Testing on real routes. We run scenarios in basements, industrial zones and areas with poor coverage: how the queue of marks behaves and how long synchronization takes.
- Pilot operation. Limited group of couriers and shifts, reconciliation of actual orders with previous process. Improvements go in short cycles, without stopping main work.
- Handover. Regulations for dispatchers and couriers, documentation on data exchange, analysis of typical failures.
Handover package: documentation, diagrams, update regulations
Courier service app lives longer than the team that made it: courier composition changes, accounting system grows new statuses, cartography moves to another service.
If after delivery only a repository remains, every change turns into archaeology through code. Therefore project handover is a separate stage with a fixed set, according to which service engineer will release a version and troubleshoot without us.
- Architecture diagram — map of screens and modules, application layers, extension points, platform dependencies.
- Integration diagrams — exchange with order accounting system, cartography, geolocation service and notification delivery: formats, error codes, retries and response timeout.
- Role and access matrix — rights of courier, dispatcher, administrator and service accounts, restrictions on access to addresses and personal data.
- Data model — order, route sheet, delivery status, local send queue when network disappears and rules for synchronization with server.
- Update regulations — branching, build signing, release channels (internal testing, closed group, production circuit), approval procedure and rollback to previous release.
- Support regulations — failure classes and response time for them, on-call duty, where to view logs and crash dumps, how to pass courier request to engineer.
- Build and environment instructions — keys, variables and configuration profiles for test and production circuits, so a new engineer can build the app without access to correspondence.
Case: removed manual calls and manual order distribution
Customer — regional delivery service Курьер-Лайн: about forty couriers, 300–400 orders per shift and one dispatcher who assembled routes manually from a spreadsheet. Every morning began with redistribution of already assigned addresses and calls to those who hadn't left yet.
Couriers changed statuses by voice over phone, so "delivered" and "client not found" reached the system with delays of tens of minutes. Dispatch received about 180 requests per shift — half were not about new orders, but about clarifying status.
What changed
Courier app received a local event queue: status, geotag and recipient signature are written to device and go to server when connection returns.
Delivery dispatching became automatic — order is assigned by zone, courier load and transport type, and dispatcher connects only to exceptions: client refusal, address out of zone, missed window.
| Metric | Before | After |
|---|---|---|
| Average time per route | 3 h 40 min | 2 h 50 min |
| Deliveries in agreed window | 78% | 94% |
| Requests to dispatch per shift | ~180 | ~35 |
| Disputed "client not found" | 9% of orders | 4% of orders |
What became
Share of orders with on-time status grew from 78% to 94%, load on dispatch fell about fivefold — freed time went to complex addresses and regular clients. Conflicting statuses are resolved by event time on device, so re-sending doesn't create a second delivery record.
What to do if the service already has an app and accounting system
Already working app and accounting system are an asset, not an obstacle: they accumulate address and tariff zone directories, order history, courier base, dispatcher access rights.
We start with inventory: we look at what data is actually used and what processes each system covers, so as not to transfer into new circuit what has long not worked.
Main restructuring — integration with dispatch. While exchange relies on scheduled exports, statuses diverge, and dispatcher clarifies delivery by call.
We switch exchange to events: order created, assigned, accepted, delivered or cancelled — each change goes as a separate record with identifier. Then re-sending doesn't create a duplicate, and discrepancy is visible in reconciliation log.
Transfer of delivery data goes by key matching: orders, clients, addresses, couriers, statuses. We separately analyze "tails" — stuck orders, duplicate addresses, outdated statuses that cannot be migrated automatically.
For transition period both systems work in parallel: old app version continues to exchange data while update reaches all devices, so courier is not left without orders mid-shift.
Modernization of courier app — primarily about reliability in the field: local queue of actions (status change, photo, recipient signature) with resend when connection appears, background location transmission designed for long shift, clear error message instead of "order not sent". Familiar screens that don't affect result are left as is.
Order of work: inventory and data reconciliation, then shadow exchange mode, and only then switching by departments with possibility of rollback to previous circuit.
Integrations, offline mode, tracking: frequently asked questions
During analysis almost always three questions come up: what will happen to order if courier loses connection, how app shares data with accounting system and how accurately courier location is visible.
Answers are determined not by screens, but by exchange and geozone rules — we fix them before development starts.
How does the app work in areas without connection?
Courier continues working on local data: tasks, addresses and statuses are stored in device storage, and each action is written to operations log. When connection returns, log goes to server in a batch in original order, and statuses in accounting system are updated.
There will be no duplicates — each operation has its own unique identifier, re-sending is recognized as the same record.
Will the app start arguing with the accounting system over data?
Source of truth is the accounting system: orders, addresses and delivery composition are maintained in it, the app is responsible only for execution progress.
Exchange goes over secure channel through integration layer, where mapping of directories, roles and statuses is described, and discrepancies go into report for analysis. New fields and statuses are added in this layer without rewriting the app itself.
How is courier tracking and delivery geozones arranged?
Route points are collected on device and sent in batches, so track remains continuous and battery consumption is predictable.
Geozone is described by polygon: when crossing it, app generates event, client receives "courier is nearby" notification, dispatcher sees status change. We take cartography and coordinates from OpenStreetMap, so zone boundaries match actual buildings.
Let's discuss the task: what to know before estimation
To come back with app project estimate and work plan, we need not a list of wishes, but an actual picture of courier service processes.
The more accurate the inputs on fleet, order logic and current systems, the fewer assumptions in estimate and the more realistic app development timelines. Below is what we analyze at first meeting.
- Fleet composition and mode: how many couriers work per shift, are they on foot or transport, staff or contractors, is a separate interface needed for dispatcher and logistician.
- Order lifecycle: what statuses delivery goes through, who and when changes them, what happens on refusal, reschedule and repeated delivery attempt.
- Geography and delivery types: cities and zones, same-day delivery or interval slots, rules for distributing orders between couriers.
- Integrations: from which system orders come, whether it has open exchange interface, how addresses, weight and shipment composition are transmitted.
- Handover confirmation: photo, signature on screen, recipient code — and what courier must record when there is no connection.
- Money in the field: cash, terminal, shift and tips settlement, whether export to accounting is needed.
- Control and reporting: which metrics management looks at daily — time en route, delays, share of failed deliveries.
Part of data usually exists only in head of operations manager — this is normal.
Describe the task as it looks today, and we will record the unknown as risks and clarify at start: based on conversation results, we will return with estimate and app work plan broken down by stages and dependencies.