How to Build a Food Delivery App in Nigeria: A Multi-Restaurant Platform Guide

What a food delivery app is: four roles, one backend

Compared with a single-restaurant app, the platform adds restaurant onboarding, commission and payout logic, multi-restaurant search and a shared rider pool. Compared with a general delivery app, it adds the restaurant acceptance step and the timing problem of hot food.

The business model and per-order arithmetic

Revenue per order typically comes from a commission on the food value paid by the restaurant, a delivery fee paid by the customer, sometimes a small service fee, and later promotional placements and subscriptions. Costs per order include rider pay, payment gateway fees, map usage, customer support, packaging where the platform supplies it, and refunds. The figures below are illustrative assumptions for a worked example, not market data. Suppose a ₦6,000 food order carries a 15% commission (₦900), the customer pays a ₦1,000 delivery fee, the rider is paid ₦900 for the trip, gateway fees take roughly ₦100, and maps, support and refunds average ₦200 per order. Platform gross margin is then ₦900 + ₦1,000 − ₦900 − ₦100 − ₦200 = ₦700 per order before marketing, staff and technology costs. Change any one assumption (rider pay up because of fuel, delivery fee down because customers resist it) and the margin can disappear. Three lessons follow. Delivery density (many orders in a small area) is what makes rider pay per trip affordable. Batching (a rider carrying two orders from nearby restaurants) improves the arithmetic further. And the commission must be one that restaurants accept while the delivery fee must be one customers accept, which in a price-sensitive market is a narrow band. Model this before writing any code.

Features by role

The order flow and the timing problem

1. Customer orders and pays (or selects cash within rules); order is sent to the restaurant.
2. Restaurant accepts and sets prep time; unaccepted orders escalate to operations, who call the restaurant.
3. The backend schedules rider dispatch so that the rider arrives near food readiness, not at acceptance; a rider waiting twenty minutes at the counter is a cost and a complaint.
4. Rider accepts, travels, confirms pickup; customer sees live position.
5. Rider delivers, records proof, collects cash if applicable.
6. Payment is split and recorded; customer rates the order.

Side paths that must be designed: restaurant rejects (item finished), restaurant delays past prep time, no rider accepts, rider cancels after pickup, customer unreachable at the door, partial refunds, and batching two orders from nearby restaurants for one rider. Hot food makes each of these more urgent than in parcel delivery.

Restaurant onboarding and menu management

Restaurants are the supply side and the platform's reputation rests on them. The onboarding module should cover:

• Sign-up and documents: business details, bank account for payouts, any registration or food-safety documents the platform chooses to require; verify any regulatory expectations with the relevant authorities.
• Commission agreement recorded in the system with the rate and effective date.
• Menu setup with modifiers, prep times and compressed images; a self-service menu editor and an option for the operations team to build the first menu for less technical partners.
• Device and alerts: the partner app on a tablet or phone in the kitchen, tested for alert volume; a WhatsApp or phone fallback when the app is unattended.
• Availability discipline: one-tap toggles and a pause mode, plus operations monitoring for restaurants that reject too often or accept too slowly.
• Payout statements that a restaurant owner can reconcile without calling support.

Restaurants that accept in under two minutes and keep their menus live are the platform's real asset. Build the tools that make that easy, and the reports that show operations who is failing.

Rider operations

Platforms choose between an own fleet with salaried riders, contract riders paid per delivery, or a partnership with local dispatch companies, and many mix them. Whatever the model, the rider app must handle:

• Shifts and zones so supply matches demand at lunch and dinner peaks.
• Timed job offers based on prep time and rider position; batching of nearby orders.
• Cash on delivery with a wallet and remittance rules, since some customers will not prepay.
• Proof of delivery, masked calls and an offline queue for status updates.
• Pay and incentives visible in the app: per-trip pay, peak bonuses, weekly totals.
• Onboarding and documents: identity, licence, bike papers, with expiries.

The guide to building a delivery app in Nigeria goes into rider app design in more depth; the food-specific additions are the timed pickup and the insulated bag that the platform should make mandatory.

Payments, splits and payouts

• Customer payment by transfer to a per-order virtual account with automatic confirmation, card, USSD, or cash on delivery within rules (order value limits, verified customers).
• Splitting the order value between platform commission, restaurant share and delivery fee. Nigerian payment gateways offer split-payment or sub-account features that can route restaurant shares automatically; alternatively the platform collects and pays out on a schedule. Confirm the approach with the gateway's documentation and a qualified adviser on any regulatory implications of holding funds.
• Restaurant payouts daily or weekly by transfer, with statements showing each order, commission and adjustments.
• Rider payouts for in-app earnings, net of cash collected and commission owed on cash orders.
• Refunds for missing items, late orders and cancellations, with rules on who bears the cost (platform, restaurant or rider).
• Reconciliation across all of this, per day, per restaurant, per rider, in the operations dashboard.

Payout accuracy is the fastest way to earn or lose restaurant trust. Statements should be correct before the customer app is polished.

How to build a food delivery app: twelve steps

1. Model the per-order economics with your own assumptions for commission, delivery fee, rider pay and costs, and identify the density needed to break even.
2. Choose the launch area: one dense district with many restaurants and customers within a short ride, not a whole city.
3. Sign the first restaurants and agree commission, menus and acceptance standards before the build finishes; supply comes first.
4. Define the order, rider and payout flows with all side paths.
5. Design the data model: customers, restaurants, menus, orders, riders, jobs, payments, splits, payouts, zones.
6. Build the backend and operations dashboard first, including restaurant onboarding and payouts.
7. Build the restaurant partner app and test alert volume and acceptance flow in real kitchens.
8. Build the rider app for Android with timed pickups, cash logging and offline tolerance.
9. Build the customer app for Android first with a web version; iOS when the audience justifies it.
10. Integrate maps, payments and messaging: routing and display, a Nigerian gateway with virtual accounts, webhooks and split payments, WhatsApp templates and SMS, push notifications.
11. Pilot for four to eight weeks in the launch area with a small rider pool and dispatcher-assisted assignment; measure acceptance times, delivery times, cancellations, refunds and margin per order.
12. Expand zone by zone only when the pilot's numbers hold; automate assignment and batching as data allows.

What changes in Nigerian cities

• Density and traffic. A delivery radius that works at 2pm fails at 7pm in Lagos or Abuja; zones should shrink at peak hours and the app should promise windows rather than exact times.
• Cash and transfer. Cash on delivery is expected by some customers and creates rider cash handling; virtual account transfers with automatic confirmation reduce it.
• Restaurant reliability. Power cuts, unattended tablets and finished items are daily realities; escalation calls, pause modes and availability toggles are core features, not extras.
• Price sensitivity. Delivery fees are compared closely; batching and density are the levers that keep fees acceptable without losing margin.
• Fuel price volatility. Rider pay and delivery fees need to be adjustable from the dashboard without an app release.
• Data costs and phones. All three mobile apps must be small and work on mid-range Android over patchy data.
• Trust and safety. Rider verification, masked calls, proof of delivery and a visible complaints process matter to customers and restaurants alike.
• Regulation and data protection. Verify any registration or food-safety expectations for platforms and partners with the relevant authorities; handle personal data under the Nigeria Data Protection Act 2023 and verify obligations with the Nigeria Data Protection Commission.
• US-dollar costs. Maps, hosting and notification services are dollar-priced; a food delivery platform is map-intensive, so cost per order should be modelled in both currencies.

Example (hypothetical): a university-district pilot in Ibadan

Consider a team planning a food delivery platform for the university and surrounding residential area in Ibadan, where dozens of small restaurants and food vendors serve students and staff within a few kilometres. This scenario is illustrative and not a client result. The team models the economics with student-level order values and concludes that margin depends on batching and a small delivery radius. It signs twenty restaurants, agreeing a commission and a rule that orders must be accepted within two minutes or the platform calls. It recruits fifteen contract riders on per-delivery pay with lunch and evening shifts. Version one: an operations dashboard with dispatcher-assisted assignment and batching, a restaurant partner app on cheap Android phones with loud alerts and pause mode, a rider app with timed pickups and cash logging, and a customer app plus web version with transfer, card and cash on delivery under a value limit. Payouts to restaurants are weekly with itemised statements. WhatsApp templates carry order status to customers without the app. After the pilot, the team reviews acceptance times, delivery times, cancellations, refunds and margin per order, then decides whether to automate assignment and expand to the next district. Indicative cost for the pilot build sits at roughly ₦8,000,000–₦15,000,000, below the usual band for a marketplace because assignment is dispatcher-assisted, tracking is basic and vendor tools are web-based; a full platform with automatic dispatch and live tracking moves into the ₦15,000,000–₦50,000,000 band (2026 ranges; actual quotes vary with scope, vendor and exchange rate).

What a food delivery app costs in Nigeria

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

The software is a fraction of the venture cost: rider incentives, restaurant acquisition, customer promotions and an operations and support team usually exceed the build. Compare two or three written quotations on identical scope and ask each vendor how their design keeps map calls per order low and how payouts are reconciled.

Mistakes to avoid

• Building before signing restaurants. Supply is the hard part; a polished app with five restaurants is an empty marketplace.
• Launching city-wide. Density in one district beats thin coverage everywhere; rider pay per trip only works with short, frequent trips.
• Dispatching riders at acceptance. Riders waiting at counters cost money and morale; time dispatch to readiness.
• Ignoring cash. Cash on delivery will happen; without a rider wallet and remittance rules, losses follow.
• Payout statements as an afterthought. Restaurants judge the platform by whether the money is right.
• Static menus and no pause mode. Orders for finished food and unattended tablets destroy customer trust quickly.
• Automatic dispatch on day one. It needs data, rules and rider trust that a new platform lacks; start assisted.
• Underestimating support. Every late order generates a message; budget people and tooling for it.

Conclusion

Building a food delivery app in Nigeria means building four connected products on one backend and, more importantly, an operation that makes the per-order arithmetic work: restaurants that accept in minutes and keep menus live, riders dispatched to arrive as food is ready, a dense launch area that keeps trips short, payments that split correctly and payouts that restaurants can trust. Model the economics first, sign supply before finishing the build, start with a lean pilot and assisted dispatch, and expand only when the numbers hold. If you are planning a multi-restaurant delivery platform and want the operations tools, partner app, rider app and customer app designed around Nigerian payment habits and city realities, Linestech can help you scope a pilot that tests the model before the full investment.

Frequently asked questions

How many restaurants and riders do I need to launch?

Enough to make the launch area feel full and the rider pool responsive: as a rule of thumb, a few dozen restaurants within a short ride of each other and a rider pool sized to peak lunch and dinner demand rather than the daily average. Run your own economics model to find the order density at which rider pay per trip works, then launch in an area that can reach it.

Can I start with a web app instead of three mobile apps?

Partly. The customer side and the restaurant dashboard can start on the web, and operations always runs on the web. The rider app should be native or cross-platform from the start because it needs background location, offline queueing and cash logging. Starting web-first for customers and restaurants lowers the pilot cost and lets you learn before investing in polished apps.

How do payments get split between the platform, restaurants and riders?

Either through the split-payment or sub-account features that Nigerian gateways provide, which route shares at the point of payment, or by the platform collecting all payments and paying out on a schedule with itemised statements. Cash orders are handled through rider wallets. Confirm the chosen approach against the gateway's documentation and take advice on any regulatory implications of holding funds.

How is the rider timed to arrive when the food is ready?

The backend uses the restaurant's stated prep time and the rider's travel time to the restaurant to schedule the job offer so that the rider arrives shortly before readiness. Restaurants update status to "ready", and repeated late readiness is flagged to operations. Batching then groups a second nearby order onto the same rider when timing allows.

What happens when a restaurant does not accept an order?

The order escalates after a set time (typically a minute or two) to the operations dashboard, and staff call the restaurant. If there is still no acceptance, the customer is informed, offered an alternative or refunded automatically. Restaurants with repeated failures are paused. Designing this flow before launch prevents the silent late orders that destroy trust.

How long does it take to build a food delivery platform?

A lean single-area pilot with dispatcher-assisted assignment can be ready within a few months from a settled economics model and signed restaurants; automatic dispatch, live tracking and automated payouts follow over subsequent months as pilot data justifies them. The economics model, the launch area and the first restaurant agreements are the biggest accelerators, and none of them is software.

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)
• Node.js documentation
• Baymard Institute e-commerce UX research