Delivery App Development in Nigeria: Scope, Cost and Choosing a Partner
Delivery is one of the most commonly commissioned app categories in Nigeria and one of the most commonly under-scoped. The visible part — a customer opening an app and watching a rider move on a map — sits on top of dispatch logic, payment handling, cash reconciliation and an offline-tolerant rider experience that together represent most of the work.
This article takes the buyer's view: what you are actually purchasing, how to scope a first release that ships, how to evaluate a development partner in Nigeria, what a proper quotation should contain, and how to avoid the contract terms that cause most disputes. If you want the technical build sequence instead, How to Build a Delivery App in Nigeria covers how to build a delivery app step by step.
What a delivery app project actually includes
| Component | Who uses it | Share of typical first-release effort |
|---|---|---|
| Customer app | Senders and consumers | Roughly a quarter |
| Rider app | Dispatch riders and drivers | Roughly a quarter |
| Admin and dispatch console | Operations team | Roughly a quarter |
| Backend, pricing engine and integrations | Nobody directly, everything depends on it | Roughly a quarter |
That last row is why delivery app quotations differ so widely. Two vendors can propose the same three screens and price them very differently because one has scoped the dispatch logic, payment reconciliation and notification infrastructure and the other has not.
A complete first-release scope usually includes:
- Customer registration, address book with landmark fields, order placement, price display, payment, tracking, history and support contact
- Rider onboarding, availability toggle, job offers or assignments, navigation handoff, status updates, proof of delivery, cash collection record and shift summary
- Admin dispatch board, rider management, pricing and zone configuration, order exceptions, refunds, reporting
- Backend services: pricing calculation, assignment logic, notifications, payment integration, audit logging
- Deployment to Google Play and the Apple App Store, and the operations documentation your team will use
Scoping version one: the feature decision
The single most useful exercise before commissioning a delivery app is to divide every feature into three columns.
Must be in version one
- Place an order with pickup and drop-off, including landmark and phone fields
- Automatic price calculation by zone and item size
- Payment: card, transfer and pay-on-delivery
- Rider assignment, whether automatic or by a dispatcher
- Status updates visible to the customer
- Proof of delivery with a one-time code or photo
- Cash-on-delivery capture and rider shift reconciliation
- Admin ability to change prices, zones and rider records without a developer
Version two, after real usage
- Live map tracking of the rider
- Scheduled and recurring deliveries
- Multi-stop orders
- In-app wallet and saved payment methods
- Ratings and rider incentives
- Merchant bulk booking and API
Rarely worth funding early
- Loyalty points schemes
- In-app chat replacing WhatsApp and phone
- Complex referral systems
- A web version duplicating the whole customer app
- Advanced analytics before you have data worth analysing
Cutting version two and three items out of the first release is usually the difference between shipping in four months and shipping in nine, and the later features are better designed once real riders and customers have used the product.
The pricing engine: the part most projects get wrong
An answer-ready summary: the pricing engine decides what a delivery costs, and it must reflect how Nigerian delivery economics actually work — zones rather than straight-line distance, item size, service level, time of day, and surcharges for waiting and re-attempts. Getting it wrong means either losing money on every long-haul drop or being uncompetitive on short ones.
Design questions to settle before development starts:
- Do you price by zone pair, by distance band, or by a base fee plus per-kilometre rate?
- How do you handle cross-river and cross-bridge trips where distance understates cost?
- What are the item size or weight categories, and who decides the category — customer or rider?
- Is there a peak or evening surcharge, and is it visible to the customer before ordering?
- What happens when the rider waits 25 minutes at pickup?
- How are failed deliveries and re-attempts charged?
- Which prices can your operations manager change from the admin console, and which require a developer?
Insist on that last point. A pricing engine only a developer can adjust will become an operational problem the first time fuel prices move.
Money, cash on delivery and payouts
Cash remains a normal payment method for Nigerian deliveries, and it creates the reconciliation problem that quietly damages delivery businesses.
Design the money flow explicitly:
- At order: record amount expected, payment method chosen, and whether the sender or receiver pays.
- At delivery: rider records amount collected and method — cash, transfer to a designated account, or POS.
- At shift end: the app produces a rider statement: jobs completed, cash held, transfers received, expected remittance.
- At remittance: the finance team matches bank credits against expected amounts, and shortfalls are flagged automatically rather than discovered weeks later.
- At payout: merchants and riders are paid on a stated schedule with a downloadable statement.
Virtual account numbers from a Nigerian payment provider can automate much of the matching. Confirm current fees, settlement timings and requirements directly with the provider; do not design a flow around assumptions.
What changes for delivery apps in Nigeria
Addresses are descriptive. "Opposite the church, off Awolowo Way" is a valid address here. Build landmark fields, a receiver phone number and a saved pin after the first successful delivery. Do not assume geocoding will resolve an address correctly.
Offline is the default state for riders. Rider apps must queue status updates, cache the job list, and sync when connectivity returns. A rider stuck at a gate with no signal must still be able to mark a delivery complete.
Battery and data are the rider's cost. Compress photos before upload, reduce location pings when stationary, and keep the app small.
Traffic makes time estimates unreliable. Quote wide delivery windows and communicate delays early rather than promising precise arrival times you cannot meet.
Cash on delivery must be first-class, not an add-on. Systems that treat COD as an exception create reconciliation gaps.
Riders change jobs. Onboarding must be fast, device deactivation must be instant, and training must take minutes.
Data protection applies. Customer addresses, phone numbers and rider location histories are personal data under the Nigeria Data Protection Act 2023. Define retention periods, restrict access by role, publish a privacy notice, and confirm your obligations with the Nigeria Data Protection Commission or a qualified adviser.
Trust is earned through proof. One-time delivery codes, photos and timestamps settle disputes that would otherwise cost you merchants.
How to choose a delivery app development partner
There is no credible public ranking of Nigerian app developers, so evaluate on evidence rather than claims. Use these criteria.
| Criterion | What to ask for | What a good answer looks like |
|---|---|---|
| Relevant experience | Apps handling location, offline use or payments | A working app you can install and use |
| Technical approach | Which framework, why, and how offline is handled | A specific justification, not a brand preference |
| Scope discipline | What they would cut from your list for version one | They push back on features, rather than agreeing to everything |
| Pricing transparency | Line-item breakdown including third-party costs | Mapping, SMS and hosting stated separately |
| Ownership | Source code, repositories, cloud and store accounts | All in your company's name, in writing |
| Testing | How they will test on low-end devices and poor networks | A named device list and a network-throttling plan |
| Support | What happens after launch and at what price | A written maintenance scope and response times |
| Team and continuity | Who does the work and where | Named roles, a single accountable contact |
Practical checks: install an app they have built and use it on mobile data. Ask to see the admin console of a previous project, not just the customer screens. Ask what they would do if the delivery volume tripled. And ask for a fixed-price first phase with a small, well-defined scope rather than committing your full budget upfront.
Be sceptical of anyone who quotes a firm price before understanding your pricing model, your payment flow and your dispatch process; these are the three things that determine the work.
What a proper quotation contains
- A written scope listing every screen and rule, not a feature summary
- A breakdown by component: customer app, rider app, admin console, backend, integrations
- Design deliverables and how many revision rounds are included
- Named third-party services and who pays for them
- Testing approach, including devices and network conditions
- Deployment to both app stores and who owns the accounts
- Milestones with payment tied to delivered, demonstrable work
- Post-launch support period and what is covered
- Maintenance pricing after that period
- Intellectual property and source-code ownership clauses
- Assumptions and explicit exclusions
If a quotation is a single figure with a five-line description, it is not a quotation. Ask for the breakdown before comparing it with anything else.
Indicative cost and timeline
Indicative 2026 ranges. Actual quotations vary with scope, vendor, integrations and the exchange rate, since hosting, mapping and messaging are typically billed in US dollars.
| Scope | Indicative cost | Indicative timeline |
|---|---|---|
| Rider app only, connected to existing operations software | ₦1,500,000–₦5,000,000 | 8–14 weeks |
| Customer app plus rider app plus basic admin, status tracking | ₦5,000,000–₦15,000,000 | 3–6 months |
| Full platform with live map tracking, merchant portal and wallet | ₦15,000,000–₦50,000,000+ | 6–12 months |
| Adding a merchant API to an existing delivery app | ₦1,500,000–₦6,000,000 | 6–12 weeks |
Recurring: maintenance typically 15–25% of build cost per year; cloud hosting ₦150,000–₦800,000+ per year; mapping, SMS and WhatsApp messaging billed by usage; Apple Developer Program at a yearly fee (historically US$99 per year) and Google Play registration as a one-time fee (historically US$25). Verify the current platform fees before budgeting.
Compare two or three quotations on identical written scope. Where prices differ sharply, the cause is almost always a difference in what the backend, dispatch logic and reconciliation include.
Example (hypothetical): a Lagos same-day delivery startup
This is an illustrative scenario, not a client result.
A new same-day delivery business plans to serve Lagos Island, Lekki, Yaba and Surulere with 12 riders, targeting fashion and gadget vendors who currently use informal dispatch riders.
A realistic version one:
- Customer app: order, zone-based price, card or transfer payment, pay-on-delivery option, status tracking, order history
- Rider app: assigned jobs, status updates, one-time-code proof of delivery, COD capture, offline queue, shift summary
- Admin console: dispatch board, zone and price editor, rider records, exceptions, daily reconciliation report
- Integrations: one payment gateway, one SMS provider, maps for display and address lookup
Deliberately excluded from version one: live map tracking, wallets, ratings, scheduled deliveries and a merchant API. Those are reviewed after three months of real operation.
Indicative budget for that scope falls in the ₦6,000,000–₦12,000,000 range over four to five months, plus recurring hosting and usage costs. The founder's success measures, agreed before the build: drops per rider per day, first-attempt success rate, COD shortfall as a percentage of cash handled, and repeat order rate by vendor.
What you must supply for the project to succeed
A delivery app project fails as often on the client side as the vendor side. Before development begins, you should be able to hand over:
- A finalised zone map and price table
- Your item size or weight categories and any prohibited items list
- Payment methods you will accept and the gateway account details
- Your delivery status list and failure reason list
- Rider pay and incentive model
- COD remittance rules and timing
- Merchant payout schedule if you serve sellers
- Your terms of service, liability position and privacy notice
- A named internal owner with authority to make decisions quickly
- Riders available for pilot testing
- Brand assets and a registered business name for store submissions
Delays in these items cause more schedule overruns in Nigerian delivery app projects than any technical issue.
Mistakes to avoid
- Commissioning before the pricing model is settled. Everything downstream depends on it, and changing it mid-build is expensive.
- Paying the full budget in two instalments. Tie payment to demonstrable milestones instead.
- Treating live map tracking as essential for version one. It adds cost and complexity; accurate statuses solve most of the customer's real need.
- Forgetting the admin console. Operations staff use it every day. It deserves as much design attention as the customer app.
- No offline handling in the rider app. This is the most common cause of abandoned rider apps in Nigeria.
- Store accounts in the developer's name. You will lose control of your own app. Insist on company-owned accounts from day one.
- Launching city-wide. Pilot one or two zones, fix what breaks, then expand.
- No budget for the second version. Delivery apps need continuous change. Reserve at least a quarter of the initial budget for the first year after launch.
Conclusion
Delivery app development in Nigeria is best treated as buying an operations system with three faces rather than buying an app. Settle your pricing model and cash flow first, cut version one to what proves the service works, insist on a component-level quotation and written source-code ownership, and pilot in a small area before expanding. The projects that succeed are the ones where the founder could describe the money flow, the status list and the failure reasons before a designer opened a single screen.
If you are scoping a delivery app and want a written, component-level breakdown before committing a budget, Linestech builds delivery and logistics applications for Nigerian businesses and can help you define version one around the numbers that matter to your operation.
Frequently asked questions
How much does a delivery app cost in Nigeria?
Indicatively, ₦5,000,000–₦15,000,000 for a customer app, rider app and admin console with payments and status tracking; ₦15,000,000 and above for platforms with live tracking, wallets and merchant integration. Rider-app-only projects connected to existing software start around ₦1,500,000. Treat all figures as indicative and compare written quotations on identical scope.
How long does a delivery app take to build?
Three to six months for a disciplined first release, assuming your zone map, pricing and payment decisions are ready when development starts. Larger platforms run six to twelve months. Projects that begin before the pricing model is agreed routinely run months longer than planned.
Can I launch with only a rider app and a WhatsApp ordering flow?
Yes, and for many young delivery businesses that is the sensible start. Orders arrive by WhatsApp and are entered by an operator into a simple admin console, while the rider app handles execution, proof and cash. It costs far less, and it proves your operations work before you spend on a consumer app.
Do I need my own delivery app or can I use existing platforms?
If deliveries are a support function for your shop or restaurant, using established delivery partners is usually cheaper and faster. Building your own makes sense when delivery is the business itself, when you have your own riders, or when your margins cannot absorb a third party's commission.
What technology should a Nigerian delivery app be built with?
Most are built with a cross-platform framework such as Flutter or React Native for the apps, a web admin console, and a cloud-hosted backend. The specific choice matters less than offline support in the rider app, a configurable pricing engine, and a clear data model. Ask vendors to justify their choice against your requirements.
How do we handle riders who do not remit cash?
Design for it. Record expected versus collected amounts per job, produce an automatic end-of-shift statement, reconcile bank credits daily, and set a remittance deadline with consequences written into the rider agreement. Systems that surface a shortfall the same day prevent losses that manual reconciliation only reveals weeks later.
Should the app support multiple cities from launch?
Build the data model to support multiple cities and zones, but operate in one city at launch. Multi-city operations introduce pricing, rider management and hub complexity that will distract you from proving the core service works.
What ongoing costs should I expect after launch?
Maintenance at roughly 15–25% of build cost per year, cloud hosting, mapping and geocoding usage, SMS or WhatsApp notification charges, payment gateway fees, app store fees, and the cost of the internal person who owns the system. Budget for all of these before you commission the build, not after.
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.
