Mobile App Development for Your Courier and Delivery Operation
A courier who heads out in the morning comes back in the evening with a paper list, signed waybills and the cash they collected. And it is the operations manager who spends the day answering recipients calling to ask where their parcel is. A courier app pulls those three disconnected pieces — assignment, proof of delivery and payment collection — into a single flow, leaving a simple screen for the courier and a live map at head office.
How many separate apps does this need?
-
01
Courier Mobile App (iOS + Android)
Shift start, an ordered list of assigned stops, a one-handed delivered/undelivered flow, barcode scanning, signature and photo proof, cash-on-delivery collection and an end-of-day cash reconciliation summary.
-
02
Sender Business App
A mobile app where the merchant or branch creates shipments, generates barcodes, requests pickups, sees where the courier is and downloads proof of delivery.
-
03
Operations and Dispatch Panel (Web)
Splitting shipments into zones, assigning them to couriers and reassigning during the day, a live map, alerts for late stops, tracking of failed-delivery reasons and cash reconciliation.
-
04
Recipient Tracking Module (Web)
An SMS link with a courier-approaching notification, an estimated delivery window, address correction and neighbour drop-off consent; runs in the browser with no app install.
What the app includes
- Shift start with vehicle and bag handover records
- Bulk accept and bulk close via barcode scanning
- Failed-delivery reason with photo and preset next step
- One-time delivery code sent to the recipient by SMS
- Card payment at the door (mPOS) plus payment link
- End-of-day courier cash sheet with back-office approval
- Geofence-triggered arrival notice near the stop
- Offline delivery queue that syncs when signal returns
- Zone polygons for assignment and mid-day reassignment
- Recipient-side address fix and neighbour drop-off consent
- Separate flow for returns and return-to-sender shipments
- Auto-generated transport filings (Turkey's UETDS) and e-waybills
State of the sector
In courier and last-mile delivery, competitive pressure comes straight from the big carriers and the marketplaces: recipients now expect to see their parcel on a map. When a regional delivery firm sits down with a merchant, the first question is not price but “can you give us a tracking link, can we download proof of delivery from the system?” Without an app, the business absorbs the load of status calls, lost paper waybills and a cash box that never balances at day's end. In a job with high courier turnover, a screen simple enough for a new hire to learn in a day translates directly into operational capacity.
Metrics that matter here
- First-attempt delivery rate — Address verification, approach notifications to the recipient and delivery-window selection directly reduce the number of stops that have to be attempted a second time.
- Stops delivered per courier per day — Stop sequencing and on-screen guidance instead of a paper list cut the decision time couriers lose inside the vehicle.
- Average time from pickup to delivery — Automatic assignment and mid-day redistribution make visible the dead time a shipment spends in the warehouse or in the wrong zone.
- Cash-on-delivery reconciliation gap — Tying every collection to a shipment and requiring end-of-day cash confirmation shows the source of any missing or late-banked amount the same day.
Common mistakes in this sector
- Collecting location continuously at the highest accuracy An app that writes a location every second kills the phone by the afternoon and the courier drops off tracking altogether. The right approach is a location service that varies frequency with movement state and is triggered by geofences near stops.
- Designing the courier screen with dispatcher logic The dense table that works in the panel does not work on a phone used standing up, one-handed, in direct sunlight and often with gloves on. The courier screen should show one stop at a time, with large touch targets and a delivery flow that closes in two steps.
- Leaving the failed-delivery reason as free text Entries like “nobody home”, “no one there” and “door not answered” produce no usable reporting and hide where the problem actually is. Reasons should be picked from a fixed list, and each reason should have a defined follow-up action as a rule.
- Keeping payment collection outside the app When cash is managed over WhatsApp messages and cards on a separate device, end-of-day reconciliation is done by hand and the source of any gap cannot be found. Collection should be part of the shipment record from the outset, with cash confirmation captured in the app.
Regulation and compliance
Courier and distribution activity requires an authorisation certificate from the Ministry of Transport, and transport movements must be reported through UETDS (Turkey's transport tracking system); the app should be built to feed those notifications automatically. e-İrsaliye (electronic waybills) comes into play for shipment documents, and e-Fatura / e-Arşiv (Turkey's mandatory e-invoicing system) compliant with GİB (Turkish Revenue Administration) for invoicing. Under KVKK (Turkey's data protection law, aligned with GDPR), the recipient's name, address, phone number, signature and delivery photo, as well as the courier's location data, are all personal data: you must define the disclosure obligation, purpose-limited collection, a retention period and role-based access. Card payments at the door must be processed through a licensed payment institution or a bank virtual POS.
The real challenges in this sector
-
Balancing background location tracking against battery life
The courier's phone stays on for the whole shift; if location is collected continuously at the highest accuracy, the device dies by midday and tracking breaks. The answer is an adaptive location service that reads speed and idle state to change sampling frequency, geofence triggers near stops, and batched rather than one-by-one location uploads. Background location permission on iOS and manufacturer-specific battery optimisation on Android both need separate handling.
-
Working offline outside network coverage
A significant share of deliveries happen in basements, lifts, closed car parks or rural areas; if the courier cannot close out a delivery without signal, the whole flow stalls. The app must queue the delivery record, signature and photo locally on the device and send them in order once connectivity returns. To stop the same record being processed twice, you need a unique operation key generated on the client and write logic on the server that refuses to accept the same key again.
-
Routes and reassignment that change during the day
The route built in the morning falls apart with urgent shipments added mid-day, recipients who are not home, and traffic. You need an engine that sequences stops against time windows, weight, volume and zone constraints, plus reassignment rules that hand a lagging courier's load over to a neighbouring zone. When the order changes on the courier's screen, the reason has to be visible too, or trust in the app disappears.
-
Proof of delivery and dispute handling
The argument between “I received it” and “I didn't” lands on the business when the evidence is weak. Signature, photo, a one-time code sent to the recipient by SMS and the location-time stamp at the moment of delivery should all be stored together. Photos should be resized and compressed on the device before upload; records must be kept tamper-evident and be downloadable in one click from the sender panel.
-
Cash on delivery and courier cash reconciliation
Once cash, card and payment links get mixed together, the courier's cash box no longer matches the system at the end of the day. Every collection must be tied to a shipment record, card payments must go through an mPOS device or a payment link, and at day's end the courier confirms their own cash summary in the app. Head office should see the gap between expected and delivered amounts reported by courier and by date.
Required integrations
- Mapping and routing services (Google Maps / HERE) for distance matrices and stop sequencing
- Payment links via iyzico, PayTR (Turkish payment providers) or Craftgate; card payments at the door through bank virtual POS and Android mPOS devices
- An e-Fatura / e-Arşiv and e-İrsaliye (Turkey's mandatory e-invoicing and e-waybill systems) integrator compliant with GİB (Turkish Revenue Administration)
- Automatic reporting of transport records to the ministry through the UETDS notification service (Turkey's transport tracking system)
- Automatic order pulls from marketplaces and e-commerce platforms such as Trendyol, Hepsiburada, ikas and Ticimax
- SMS and WhatsApp Business notifications: dispatched, approaching, delivered, plus one-time delivery codes
Who this page is for
-
Regional distributor working out of a single depot
The weight sits on intake, assignment and proof. Barcodes, stop lists, an offline queue and a dispatch panel are enough in phase one; zone polygons with manual reshuffles beat a routing engine early on.
-
E-commerce seller building an in-house courier team
The priority is turning marketplace and store orders into shipments automatically, plus a recipient tracking link and a returns/RTS flow. Since they deliver to their own customers, branded tracking and window notifications matter most.
-
Newly founded intra-city courier startup
A shipment-creation screen you can demo to sellers, zone and pricing setup and proof download are needed from day one, because that is the sales argument. Collection and regulatory filings can wait until real volume arrives.
A phased plan that splits the budget
-
1
Phase 1 — Delivery core running in a single zone 5-7 hafta
Shipment records, barcodes, manual assignment, stop list, delivered and failed flows, signature and photo proof, offline queue. One zone runs end to end here, so the paper list disappears before any routing engine exists.
-
2
Phase 2 — Collection, recipient tracking and the sender side 4-6 hafta
Cash and card collection at the door, end-of-day reconciliation, recipient tracking link with arrival notice, the sender app and downloadable proof of delivery. Money and customer communication attach safely only once Phase 1 is already producing proof.
-
3
Phase 3 — Scaling: routing, zones and regulatory integrations 5-8 hafta
Stop sequencing and mid-day reassignment engine, zone polygons, marketplace order pull, handover of out-of-city parcels to national carriers, transport filings and e-waybills. These can only be tuned once real delivery data exists; built early, they are tuned on guesses.
Typical scope and timeline
A typical scope covers the courier mobile app (shift, stop list, barcode, proof of delivery, payment collection), the sender app, the web dispatch panel and the recipient tracking link. That includes the offline queue, adaptive location tracking, role-based permissions, notification infrastructure, one payment provider and one marketplace integration, field testing and store publishing. A route optimisation engine and e-İrsaliye (electronic waybills) are usually left to a second phase.
Estimated timeline: 10-16 weeks
Off-the-shelf or custom build?
| Topic | Off-the-shelf | Custom build |
|---|---|---|
| Zone-specific delivery rules | Off-the-shelf tools ship with standard delivered and failed reasons and work from day one, but rarely enforce local practices such as leaving a parcel with a building caretaker or block-level delivery in an industrial estate. | Reasons, the follow-up step behind each reason and which proof is mandatory are defined around your own operation, and the courier screen enforces that sequence. |
| Connecting to existing systems and marketplaces | Ready-made connectors to common marketplaces usually exist and rebuilding them would be wasted cost; but if your own accounting or warehouse software is not on their list, you fall back to file exports. | The build connects directly to your ERP, accounting or warehouse system, so shipment, collection and invoicing move on one record and double entry disappears. |
| Monthly per-courier cost vs one-off investment | A per-courier subscription is the cheapest and fastest start with a handful of couriers, and seasonal riders are easy to add or drop. The same model gets expensive as the team grows and each extra module is billed. | Custom development front-loads the cost; afterwards the licence bill does not grow with courier count, leaving predictable running costs such as hosting, store fees and maintenance. |
| Ownership and portability of proof-of-delivery data | The vendor carries backup and uptime, which is a real burden lifted from a small team; but signatures and delivery photos live in the vendor's system and bulk export is often limited. | Proof files and shipment history stay on your own servers, so in a dispute with a seller or a tender you can export records in any format and set retention periods yourself. |
Sector glossary
- Last mile
- The leg from the local depot to the recipient's door. Most of a courier operation's cost and most of its failures occur here, and this is the leg the app actually runs.
- POD (proof of delivery)
- The bundle that shows a delivery happened: signature, photo, the one-time code the recipient entered, location and timestamp. In a dispute with a seller it is the only thing you can rely on.
- Dispatch desk
- The central role that splits shipments into zones, assigns them to couriers and reshuffles the load when someone falls behind. In most firms the panel's real user is a single dispatcher.
- RTS (return to sender)
- A parcel going back to the seller after the agreed number of attempts fails. It needs its own barcode status and its own billing, so it is tracked apart from the normal delivery flow.
- Delivery window
- The time band promised to the recipient in which the courier should arrive. A narrower band means the recipient is home but the route loses flexibility; the balance is set per zone.
Frequently asked questions
Let us talk about your project
A free 30-minute call to scope it out, then an itemised quote within 48 hours.
Get a Free QuoteThis page explains the problems an app must solve in this sector. We share references and comparable projects during the call.