Parcel Tracking App Development for Courier Firms

Q: Will the app work in a basement with no internet?

Yes, offline operation is a hard requirement in this sector. The route list is downloaded to the device at the start of the shift; scans, signatures, photos and failed-delivery reasons are all recorded without a connection. When the device is back online the queue is sent in order and conflict rules are applied. The only thing the courier sees on screen is the number of records not yet sent.

Q: Will the system keep up if my shipment volume grows?

The architecture is built around scan volume from day one: scan records are a write-heavy flow, while customer lookups are read-heavy. Once those two are separated, going from a few hundred shipments a day to several thousand is solved by scaling servers rather than by a rewrite. As your corporate customer count grows, API quotas and branch-level permissions are defined from the panel.

How many separate apps does this need?

01

Sender and Recipient App (iOS + Android)

Look up a shipment by tracking number or phone number, push notifications on every status change, live courier location once the parcel is out for delivery, changes to delivery address and time window, return requests and access to the delivery record.
02

Delivery Staff App (Android first)

Route list at the start of the shift, scanning by barcode reader or camera, offline queue, name and signature of the person receiving the parcel, photo proof of delivery, cash on delivery, failed-delivery reason codes and retry records.
03

Branch and Transfer Hub App

Intake, dispatch, transfer and delivery scans; bulk barcode assignment under a bag or pallet, count discrepancy reports, a continuous phone-camera scanning mode for sites without handheld terminals, and vehicle loading checks.
04

Web Admin Panel

Shipment search, route and courier assignment, delivery performance, loss and damage cases, corporate customer contracts and rate cards, integration keys, a call centre screen and UETDS (Turkey's transport tracking system) filing records.

What the app includes

Automatic pricing from volumetric weight (desi) rules
Printing shipment labels on site via Bluetooth thermal printer
Missing-piece alert on multi-piece shipments
Recipient reschedules address or delivery window in-app
Leave-at-door, neighbour handover and delivery PIN options
Branch pickup with shelf location and holding-time counter
Reverse pickup flow for returns collected from the recipient
Vehicle loading manifest with piece-count reconciliation
Geofenced arrival scans at branches and transfer hubs
Bulk shipment upload from spreadsheet plus batch label PDF for business accounts
Photo-backed damage report recorded at intake
Statuses from contracted carriers merged into one tracking screen

State of the sector

In courier and last-mile delivery, competition comes less from price than from visibility. An e-commerce seller does not want to work with a carrier that cannot open a shipment through an API or give its customer a real-time status; recipients, meanwhile, now expect on every parcel the live tracking they see in the big carriers' apps. At a regional firm with no tracking system, the customer service line fills up all day with “where is it” calls, undelivered parcels go back on the vehicle for a second run, and no evidence can be produced for loss cases. All three translate directly into cost and directly into lost contracts.

Metrics that matter here

First-attempt delivery rate — Telling the recipient an arrival window and taking address or time changes through the app reduces the cost of a second run.
Time from intake to delivery — Because every scan point is timestamped, you can tell whether the delay happened at the branch or in transfer.
Call centre contacts per shipment — Once status notifications and live tracking are in place, “where is my parcel” calls fall measurably.
Unscanned shipments and lost-trail rate — Shipments never scanned at some point in the chain are reported; this is where the source of loss and damage cases becomes visible.

Common mistakes in this sector

Designing the courier app as nothing but a map A courier does not stare at the screen and works one-handed. Small buttons and multi-step flows get abandoned in the field, and records get entered in bulk in the evening. The delivery screen has to be finishable with one hand and a few taps.
Leaving offline support until later If you build the online version first and postpone sync, the data model ends up one-directional and adding offline support later means a rewrite. The queue and the conflict rules have to be designed from day one.
Storing statuses as free text When phrasings like “on the way”, “out for delivery” and “on the vehicle” are generated on different screens, the customer sees two different things in two places. Statuses must be defined as a fixed state machine and written from a single source.
Uploading delivery photos without compression High-resolution photos burn through the courier's data plan and battery, and uploads stall in the field. Photos should be reduced on the device to the point that still preserves evidential value, queued, and sent in the background.

Regulation and compliance

The data processed in parcel tracking is heavily personal data: the recipient's name, address and phone number, the delivery signature, the delivery photo and the courier's location. Under KVKK (Turkey's data protection law, aligned with GDPR) you need a privacy notice, a clear position on where explicit consent is required, defined retention periods and a deletion policy; courier location must be collected only during the shift and only for business purposes. Depending on the type of operating licence held for the transport activity, a UETDS (Turkey's transport tracking system) filing obligation arises. Freight invoices fall under the e-Fatura / e-Arşiv (Turkey's mandatory e-invoicing) regime and are submitted to GİB (Turkish Revenue Administration). The app's data flows have to be designed around these obligations.

The real challenges in this sector

Connections that drop in basements, warehouses and lifts

A large share of deliveries happen where there is no signal. Scans and signatures are written to a local queue on the device and synced with a sequence number and device timestamp once the network returns. If the same barcode is scanned twice, the status must not roll backwards: a state machine runs on the server, and a late-arriving older record is written only into the history rather than overwriting the current status.
Barcodes, QR codes and labels that will not scan

Code 128, ITF and QR codes all circulate in the field, and labels get creased, wet or wrapped under stretch film. Camera scanning is supported with autofocus and the torch, and in continuous scanning mode dozens of parcels can be linked to a bag in seconds. For unreadable labels, there is manual search by the last four digits and an input path on the same screen for handheld terminals that emulate a keyboard.
Battery life on a phone that stays on all shift

A courier's phone shares location for eight hours. GPS at fixed intervals drains the battery by the afternoon, and when the device dies tracking stops. Location is collected using a distance threshold and motion detection: it thins out at a stop and speeds up when the vehicle moves, and points are sent in batches. A foreground service handles Android background restrictions, with significant location change configured separately for iOS.
Cash on delivery and the evening reconciliation

Payment at the door is taken in cash, by card and sometimes by payment link; if the courier's cash box and the system disagree in the evening, an argument about liability begins. Every collection is tied to a shipment record, the courier confirms the total at the end of the shift, and any amount that does not match a POS or virtual POS record is flagged in a report. A settlement statement is produced for paying the sender company.
Proof of delivery that stands up in a case file

In loss and damage cases, the words “delivered” are not enough on their own. The signature is stored as a vector, the photo with location and timestamp, and the name of the recipient together with their relationship to the addressee. Photos are compressed enough not to eat data in the field without losing evidential value; records are kept in a tamper-evident form and laid out on a single screen when a case is opened.

Required integrations

Ministry web service for UETDS (Turkey's transport tracking system) transport filings
e-Fatura / e-Arşiv (Turkey's mandatory e-invoicing system) integrator for freight invoices and submission to GİB (Turkish Revenue Administration)
iyzico, PayTR or Craftgate (Turkish payment providers) for payment links and online collection
Bank virtual POS and mobile POS devices carried by couriers
Shipment creation API for Ticimax, İdeasoft, Shopify and the Trendyol/Hepsiburada marketplaces
Mapping and routing service (address validation, distance matrix) plus SMS and push notification providers

Who this page is for

A newly founded city-wide courier firm with one branch and a few vehicles

A courier app with barcode scanning, an offline queue and proof of delivery is enough to start. With a single branch there is no need for hub transfer modules, route optimisation or a business API; those matter once a second vehicle group and a second branch appear.
An online retailer building its own courier team

The centre of gravity is the link to your own order system: a shipment should open automatically when an order is confirmed, the returns pickup flow belongs in phase one, and cash-on-delivery reconciliation must feed accounting. A business-client portal and a tariff engine are usually not needed at all.
A regional distribution company working through contracted carriers

Without your own couriers this is not an operations build but a status-consolidation and customer-communication project: statuses pulled from several carriers' tracking services mapped into one vocabulary, delay alerts, and a single screen for the customer. Leaving out barcode, routing and payment modules cuts the scope substantially.

A phased plan that splits the budget

1

Phase 1 — Working core for one branch and your own couriers 7-9 hafta

Shipment creation, barcode and label generation, courier route list, scanning, offline queue, signature and photo proof of delivery, plus a recipient tracking screen with status notifications. This alone replaces the paper delivery sheet from day one. It comes first because the status model and scan records are the foundation every later module sits on.
2

Phase 2 — Money, branch network and business customers 6-8 hafta

Cash-on-delivery with end-of-shift reconciliation, volumetric (desi) tariffs and invoicing, branch intake and dispatch scans, vehicle loading manifests, hub transfers, and bulk upload plus a shipment-creation API for business accounts. These modules need the scan history produced in Phase 1 to lean on, which is why they come second.
3

Phase 3 — Route optimisation, regulatory reporting and scale 6-9 hafta

Stop sequencing with time windows, estimated arrival ranges and delay prediction, automatic submission of U-ETDS transport notifications (Turkey's mandatory transport reporting system), e-Fatura/e-Arşiv invoice integration (Turkey's e-invoicing regime), loss and damage case handling, and a call-centre screen. It comes last because optimisation and statutory reporting can only be tuned once a few months of real field data exist.

Typical scope and timeline

A typical initial scope: the recipient app, the courier app and the web panel; barcode scanning, offline queue, proof of delivery, cash on delivery, status notifications and one e-commerce integration. The branch scanning module, UETDS filing and the corporate customer API are usually added in a second phase. UI/UX, store assets and store submission are included. Scope and budget are agreed after a scoping call.

Estimated timeline: 12-18 weeks

Off-the-shelf or custom build?

Topic	Off-the-shelf	Custom build
Time to first delivery	An off-the-shelf delivery platform can be live within days; barcodes, statuses and a courier screen work out of the box. For a newly founded carrier that is a genuine advantage.	Custom development takes weeks to reach a first working version. In return, labels, the status vocabulary and the delivery flow follow the actual steps of your operation.
Sector-specific workflow	Packaged tools assume a standard flow: scan, sign, close. Branch pickup, delivery PINs, multi-piece shipments or reverse pickups are often missing, or squeezed into free-text fields.	Non-delivery reason codes, retry rules, your own volumetric tariff and your branch-and-hub structure are modelled exactly; the courier screen is shortened around the case you actually see most.
Per-shipment subscription vs one-off investment	Paying per user or per shipment is cheap at low volume and protects cash flow. As volume grows the same fee scales up with it and becomes a permanent operating cost.	Custom work concentrates the investment up front, leaving hosting and maintenance afterwards, so unit cost falls as volume rises. At low volume, however, it pays back later than a subscription.
Data ownership and portability for business clients	Scan history, delivery photos and signatures live in the vendor's system. Some packages offer regular exports; where they do not, access to evidence for a loss or damage claim depends on the vendor.	The database and evidence archive stay under your control; you set your own retention and deletion policy under KVKK (Turkey's data protection law) and can expose the API and reports a business client asks for.

Sector glossary

Desi (volumetric weight unit): In Turkish parcel shipping, price follows the space a parcel occupies rather than its weight. Length by width by height divided by a fixed divisor gives the desi figure, and whichever is larger — desi or actual weight — is billed. Most tariff disputes start here.
Manifest: The formal list of shipments loaded onto one vehicle or one run. Barcodes scanned during loading are checked against the manifest, so a missing or extra piece surfaces before the vehicle leaves; afterwards, assigning responsibility gets much harder.
Transfer hub: The point where parcels collected from branches are sorted and reloaded by destination branch. A parcel is scanned here at least twice, and comparing those two timestamps is the only way to tell whether a delay happened at the branch or in transfer.
Reverse pickup: A job where the courier collects a parcel from the customer instead of delivering one, common for e-commerce returns. It is a separate flow on the courier screen, because the label is printed on the spot and the contents rest on the customer's declaration.
Non-delivery reason code: A code chosen from a fixed list, rather than typed as free text, explaining why a delivery failed: nobody at the address, wrong address, refused, payment not made. The retry rule and the message sent to the customer both depend on which code was picked.

Frequently asked questions

Should I build an app for my own courier company, or one that tracks shipments sent through carriers like Yurtiçi and Aras?

These are two different projects. If you run your own vehicles and couriers, you need a full operations system with barcodes, routing, proof of delivery and collections. If you work with contracted carriers such as Yurtiçi or Aras (Turkish courier companies), a narrower app that pulls status from their tracking services and shows it to your customer on one screen is enough. Clarifying which one you are in during the first call determines the budget directly.

Is scanning with a phone enough, or do I need handheld terminals?

If a branch does hundreds of scans a day at intake, a handheld terminal is faster and more durable. For a courier out on delivery, the phone camera is enough in most cases; with continuous scanning mode and light control a label reads in under a second. The app is built to support both: the terminal enters data like a keyboard, the phone reads with the camera, and the same record is created on the back end.

If customers can see the courier's live location, doesn't that make couriers uncomfortable?

That is exactly why location is shared conditionally rather than continuously. The map opens once the courier has taken that parcel out for delivery and it is one of the next few stops; sharing ends when the delivery is complete. No location is collected outside shift hours. In many cases showing the recipient an estimated arrival window is enough, and it cuts call volume just as much as a live map.

Will the app work in a basement with no internet?

Can UETDS filings be submitted automatically from the app?

Depending on the scope of your operating licence, transport filings can be sent to the Ministry's web service. Trip and shipment records created in the app are mapped to the filing fields and submitted; failed filings are listed in the panel and retried. Because the type of licence you hold determines the scope of your filing obligation, your existing documents and processes need to be reviewed together at the start of the project.

Will the system keep up if my shipment volume grows?

Other sectors

All sectors →

Parcel Tracking App Development: One System From Pickup to Signature

How many separate apps does this need?

Sender and Recipient App (iOS + Android)

Delivery Staff App (Android first)

Branch and Transfer Hub App

Web Admin Panel

What the app includes

State of the sector

Metrics that matter here

Common mistakes in this sector

Regulation and compliance

The real challenges in this sector

Connections that drop in basements, warehouses and lifts

Barcodes, QR codes and labels that will not scan

Battery life on a phone that stays on all shift

Cash on delivery and the evening reconciliation

Proof of delivery that stands up in a case file

Required integrations

Who this page is for

A newly founded city-wide courier firm with one branch and a few vehicles

An online retailer building its own courier team

A regional distribution company working through contracted carriers