How to Build a Delivery App in Nigeria: Customer, Rider and Dispatch in One System

What a delivery app is: three roles, one backend

A delivery app is a system that moves a parcel from a sender to a receiver through a rider, with everyone able to see where it is. Three roles use it:

• The customer (or the merchant sending on a customer's behalf) books a delivery, gets a price, pays or chooses cash on delivery, and tracks it.
• The rider receives jobs, navigates to pickup and drop-off, collects cash where required, and records proof of delivery.
• The dispatcher or admin sees all jobs and riders, assigns and reassigns, handles exceptions, sets prices and zones, and reconciles money at the end of the day.

All three run on one backend, and the backend is where most of the value and most of the work sits. A common mistake is to think of the customer app as the product. In practice, the dispatcher dashboard and the rider app are what change the business; the customer app is the front door. For a dispatch company, there is often a fourth role: the merchant, typically an Instagram or WhatsApp vendor who books several deliveries a day, wants a monthly account, and needs to give the dispatch company their customer's address without retyping it.

The order lifecycle you must define

Every delivery passes through states, and the app must know what each state means, who can change it and what message it triggers. A typical lifecycle:

1. Requested: customer or merchant has submitted pickup, drop-off and parcel details; price shown.
2. Confirmed: payment received, or cash on delivery accepted within rules.
3. Assigned: a rider has been allocated (by dispatcher or automatically) and has accepted.
4. En route to pickup: rider has started; customer can see the rider's position.
5. Picked up: rider confirms collection, optionally with a photo.
6. En route to drop-off: tracking active; receiver notified.
7. Delivered: proof recorded (photo, receiver name, OTP code); cash collected if applicable.
8. Failed: receiver unreachable or refused; reason recorded; return or retry scheduled.
9. Returned or cancelled: parcel back with sender or booking cancelled, with fee rules applied.

Write this lifecycle down with the rules for each transition (who, when, what fee) before development starts. Unwritten rules become arguments between riders, dispatchers and customers later.

Features by role

Version one for a dispatch company usually means the dispatcher dashboard, the rider app and a simple booking flow (which can begin as a web page or even a WhatsApp-assisted form). Automatic dispatch, merchant self-service and tracking maps can follow.

Pricing models and delivery zones

Delivery pricing in Nigerian cities is usually one of three models, or a blend:

Most dispatch companies start zone-based because customers understand it and it matches how they already quote. The app should display the price before the customer commits, show any surcharges (after-hours, waiting time, return trips) and let the dispatcher override in exceptional cases with a recorded reason.

Solving the address problem in Nigeria

Street numbering is inconsistent, estates have gates, and the receiver often explains the last part by phone. A delivery app has to accept this rather than fight it. Practical measures:

• Map pin as the primary address, with the typed address and a landmark as supporting text ("opposite the blue church, second gate").
• Receiver phone number is mandatory, and the rider app has a one-tap call button.
• Saved receivers for merchants, so a vendor sending to the same customers does not retype addresses.
• Area or estate selection from a list that maps to zones for pricing, even when the exact location is vague.
• Rider-corrected pins: when the rider delivers, the app records the actual GPS position, improving the address for next time.
• Delivery windows rather than exact times, since Lagos traffic makes promises unreliable.

The article on how to add Google Maps to a mobile app covers the map integration itself, including usage costs, which are priced in US dollars and should be budgeted.

Rider assignment: manual, assisted or automatic

• Manual assignment by a dispatcher who knows the riders and the city is how most companies start, and the app should make it fast: a job list, a rider list with current position and load, drag or tap to assign.
• Assisted assignment suggests the nearest available rider or the rider already heading that way, and the dispatcher confirms. This is the practical sweet spot for companies with 10 to 50 riders.
• Automatic assignment offers the job to riders by rules (nearest, best rating, fewest jobs) with a countdown to accept. It suits larger fleets and marketplaces but needs reliable rider GPS and clear rules for what happens when nobody accepts.

Build manual first with the data model ready for assisted and automatic later. Batching (one rider carrying several parcels along a route) is common in Nigeria and must be supported from the start, at least as a manual grouping.

Cash on delivery and rider reconciliation

Cash on delivery remains normal for many Nigerian receivers, especially for purchases from Instagram vendors. The app must therefore track money that riders physically carry:

• Each cash-on-delivery job records the amount to collect and, at delivery, the amount collected.
• The rider's daily cash position (collected minus remitted) is visible to the rider and the dispatcher.
• Remittance happens by transfer to the company's account or by cash handover, recorded in the app.
• Merchants see what was collected on their behalf and receive payouts on an agreed schedule.
• Discrepancies raise an alert rather than being discovered at month end.

Prepaid options (virtual account transfer, card, USSD through a Nigerian gateway) reduce cash handling and should be encouraged with small incentives. Where the business acts as a collection agent for merchants, confirm any regulatory implications with a qualified adviser.

How to build a delivery app: eleven steps

1. Document the operation as it runs today: how bookings arrive, how riders are chosen, how cash flows, what goes wrong. The app should fix the real problems, not imagined ones.
2. Define the order lifecycle with transition rules and fees.
3. Set the pricing model and zones, with surcharges and override rules.
4. Decide the roles and permissions: customer, merchant, rider, dispatcher, finance, owner.
5. Design the data model: jobs, riders, customers, merchants, zones, payments, cash ledgers, proof of delivery.
6. Build the backend and dispatcher dashboard first. The dashboard should be usable on a laptop and on a phone.
7. Build the rider app for Android, with offline queueing, background location, low battery use and large buttons for use on a bike in sunlight.
8. Build the booking front end: a web booking page and merchant portal first, then the customer app once volume justifies it.
9. Integrate payments and messaging: a Nigerian gateway with virtual accounts and webhooks; WhatsApp Business Platform templates and SMS for status updates; push notifications for the apps.
10. Pilot with a subset of riders and merchants for two to four weeks, running the old WhatsApp process alongside. Fix what riders complain about; they will find the problems fastest.
11. Roll out, train, and measure: on-time rate, failed deliveries, cash discrepancies, jobs per rider per day, against the pre-app baseline.

What changes for Nigerian businesses

• Rider phones are the weak link. Riders often use low-end Android phones with cracked screens and little storage. The rider app must be small, tolerate poor connectivity, and not drain the battery with continuous high-precision GPS.
• Voice notes are the incumbent. Riders and customers are used to explaining addresses by voice. The app should reduce calls, not ban them; masked calling and a "call receiver" button keep the human channel while logging that it was used.
• Traffic makes ETAs a promise you cannot keep. Show delivery windows and live position rather than a countdown.
• Cash is normal. See the reconciliation section; a delivery app without a cash ledger will not match how the business actually operates.
• Merchant relationships drive volume. Instagram and WhatsApp vendors send most parcels; a merchant portal with saved receivers, bulk booking and monthly statements is often more valuable than the consumer app.
• Power and data at the dispatch office. The dispatcher dashboard should work on a phone over mobile data when the office has no power.
• Rider onboarding and documents. Store rider identity, licence and bike documents in the admin, with expiry reminders. Verify any regulatory requirements for dispatch operations with the relevant state authority, as rules vary by state and change over time.
• Data protection. Receiver names, phone numbers and locations are personal data under the Nigeria Data Protection Act 2023; limit retention and access, and verify current obligations with the Nigeria Data Protection Commission.

Example (hypothetical): a Lagos dispatch company with 20 riders

Consider a dispatch company on the Lagos mainland with 20 riders serving around 150 Instagram vendors. This scenario is illustrative and not a client result. Today, vendors send pickup requests to a WhatsApp line, a dispatcher copies them into a spreadsheet, calls riders to assign, and riders phone receivers for directions. Cash collected for vendors is remitted by transfer at night, and disputes about who collected what take hours each week. Vendors complain that they cannot tell customers where their parcel is. The company builds the system in three stages. First, a dispatcher dashboard and rider app: jobs are entered by the dispatcher from WhatsApp messages, assigned with a tap, and riders update status, record cash and take a delivery photo. Cash discrepancies drop within weeks because every collection is logged at the moment it happens. Second, a merchant portal: vendors log in, book from saved receivers, see status and get a monthly statement; the dispatcher's copy-and-paste disappears. Third, a customer tracking link sent by WhatsApp to receivers, and later a small customer app for repeat senders. Indicative cost across the three stages sits in the ₦5,000,000–₦15,000,000 band (2026 ranges; actual quotes vary with scope, vendor and exchange rate), with the rider app's offline behaviour, the cash ledger and the map usage as the main drivers. The company measures success on failed deliveries, cash discrepancies and dispatcher time per job.

What a delivery app costs in Nigeria

As indicative 2026 ranges, with actual quotes varying by scope, vendor and exchange rate:

Map usage deserves a line of its own in the budget, since live tracking and route calculations are charged per request in US dollars. Ask vendors how they minimise map calls. Compare two or three written quotations on identical scope, and check that the rider app's offline behaviour and the cash ledger are explicitly included.

Mistakes to avoid

• Building the customer app first. The dispatcher dashboard and rider app change the operation; the customer app is a front door that can wait.
• Treating addresses as text. Without map pins, landmarks and receiver phone numbers, the app inherits every problem of the WhatsApp process.
• No cash ledger. If riders' cash is not tracked in the app, the biggest source of loss and dispute stays untouched.
• Continuous high-precision GPS. It kills rider batteries by noon. Use interval-based location with higher precision only near pickup and drop-off.
• Automatic dispatch on day one. It needs data, rules and rider trust that a new system does not yet have.
• Ignoring failed deliveries. Receiver unreachable, wrong address, refused parcel: each needs a state, a fee rule and a return flow.
• Skipping the merchant portal. For dispatch companies, merchants generate the volume; serving them well matters more than a polished consumer app.
• No pilot. Running the new system alongside WhatsApp for a few weeks with a handful of riders exposes problems cheaply.

Conclusion

Building a delivery app in Nigeria means building three connected tools on one backend: a dispatcher dashboard that replaces the spreadsheet, a rider app that records status, proof and cash even without network, and a booking front end for customers and merchants. Define the order lifecycle, the pricing zones and the cash rules first, solve addresses with map pins and phone numbers rather than text, start with manual dispatch, and pilot alongside the WhatsApp process before switching. Measured on failed deliveries, cash discrepancies and jobs per rider, a well-built system pays for itself in operations before the customer app is even launched. If you run a dispatch business or deliver your own products and the WhatsApp-and-spreadsheet process is straining, Linestech can help you map the operation, design the three-role system and build it in stages that match your volume.

Frequently asked questions

Do I need a separate app for riders and customers?

Usually yes. The rider app needs background location, offline queueing, cash logging and large controls for use on a bike; the customer app needs booking, payment and tracking. Combining them in one app with different logins is possible for small operations, but the rider experience suffers and the app grows heavy on low-end phones. The backend is shared either way.

Can the app work when the rider has no network?

It must. The rider app should store status updates, photos and cash entries locally and send them when the connection returns, showing the rider clearly what is pending. The dispatcher dashboard should show the last known position and time, so a rider in a dead zone is not mistaken for a missing rider.

How does live tracking work without expensive map costs?

The rider's phone sends its position to the backend at intervals (more often near pickup and drop-off, less often in transit). The customer's tracking view draws that position on a map. Costs come from map display and route calculations, not from position updates, so limiting route calculations and using tracking links that expire keeps the bill manageable. Budget in US dollars.

Should merchants pay per delivery or on a monthly account?

Offer both. Walk-in senders pay per delivery by transfer or card before pickup. Regular merchants prefer a monthly account with a statement and a credit limit, because they book several times a day. The app should track the balance, warn the merchant near the limit and let the dispatcher pause bookings on overdue accounts.

What proof of delivery should the rider record?

At minimum, a photo of the parcel at the drop-off point and the receiver's name. Stronger options are a one-time code sent to the receiver by SMS or WhatsApp that the rider enters, or a signature on screen. Proof of delivery ends most disputes about whether a parcel arrived, so make it mandatory and quick.

How long does it take to build a delivery app?

The dispatcher dashboard and rider app can be piloted within a few months from written requirements; the merchant portal, customer app and tracking typically follow over the next few months. Automatic dispatch and routing are later phases. The written order lifecycle and pricing rules are the biggest accelerators; without them, the first weeks are spent discovering rules that already exist in the dispatcher's head.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Commission (NDPC)
• WhatsApp Business Platform — Meta for Developers
• Node.js documentation