A complete logistics platform is made of three experiences and one engine, a customer app, a rider app and an admin dashboard, all running on a shared backend. The customer app books and tracks deliveries, the rider app runs the job and records earnings, the dashboard lets your team operate the business, and the backend keeps all of them working from the same records.
If any one of the three is missing, someone fills the gap by hand, usually on WhatsApp or a spreadsheet. This guide explains what each part should do, how data flows from booking to payout, and which gaps to watch for when comparing builds.
The three sided system, customer app, rider app and admin dashboard
Think of a delivery as a conversation between three parties. The customer wants a parcel moved and wants to know where it is. The rider wants a fair job, clear directions and prompt pay. Your operations team wants to see everything, fix problems and understand the numbers. Each party needs its own tool, because their goals and the information they need are different.
What makes it a system, not three separate apps, is that they share one set of records. When a rider marks a delivery complete, the customer sees it, the dashboard updates and the rider's earnings change, without anybody retyping anything.
The customer app book, pay and track
The customer app should let a person book a delivery with pickup and drop-off details, whether it is a parcel or an errand. It should show the price before the customer confirms, take payment in the app, show which rider has been assigned, and let the customer follow the delivery with a live position and ETA. At the end, a drop off code or proof of delivery confirms the handover, and a history keeps every delivery and receipt in one list.
The test is simple can a customer complete a delivery without calling your office? Every call you avoid is time your team can spend on exceptions. In ServiceBlocks Build / Logistics, the customer experience covers booking, a price quote, rider assignment, live tracking, proof of delivery and delivery history. These are mobile apps published on the App Store and Play Store, and ServiceBlocks' Mobile App Development service covers that kind of work. https://serviceblocks.biz/services/mobile-app-development/
The rider app accept, deliver and get paid
A rider app has a different job, it must help a rider decide whether to take a job, get to the right places and prove the work was done. That means going online when available, seeing the fare, distance and route before accepting, and navigating to each stop. Handovers are confirmed with a code, and the delivery moves through clear stages from offered to paid. https://serviceblocks.biz/services/backend-api-development/
Money matters just as much. Riders should see their earnings build through the day, check their ratings and receive payouts to a bank account. A rider who can check their own pay without calling the office is more likely to stay. Our guide to dispatch rider management software goes through the rider side features in detail.
The admin dashboard, where your team runs the business
The dashboard is what turns apps into a business system. Your team should see every open delivery with its status and ETA, and every rider who is online, on a live map. They should be able to assign, reassign or chase jobs, set prices by base fare, distance, vehicle and fees, review payments and rider payouts, approve rider documents, and handle disputes, cancellations and refunds. Analytics should show volume, revenue, on-time rate and activity by zone.
Configuration belongs here too. Zones, rates, vehicle types and feature switches should be settings your team can read and change, not code changes you pay for each time. In ServiceBlocks Build / Logistics, anything outside the configurable list is scoped and quoted before it is built.
The shared backend and API
The backend, often called the core, is the part nobody sees and everybody depends on. It stores orders, users, prices, payments and records, and it is the single source of truth that the three experiences read from and write to. In ServiceBlocks Build / Logistics, it handles orders, pricing, dispatch, tracking, payments, proof of delivery, rider payouts and reporting.
Its quality decides how reliable everything above it is. Ask who hosts it, how it is monitored, how often data is backed up and what happens when something fails. These are ongoing jobs, which is why technical operations from ₦150k a month cover hosting, monitoring, backups and fixes. For operators who need custom integrations or a bespoke core, ServiceBlocks also offers Backend & API Development. https://serviceblocks.biz/services/backend-api-development/
How data flows from booking to payout
Follow one delivery through the system to see why the shared backend matters.
1. A customer books a delivery and sees the price before confirming.
2. The order is recorded in the backend and appears on the operations dashboard.
3. A rider who is online is offered the job, sees the fare, distance and route, and accepts.
4. The customer sees the rider assigned and follows their live position.
5. At pickup, the rider verifies the handover, and the status updates for the customer and the dashboard.
6. At drop off, a code or proof of delivery confirms completion.
7. The payment is recorded against the order, and the rider's earnings are updated.
8. The rider is paid out, and the delivery appears in reports and in your reconciliation of what was paid and what is owed.
Nobody retyped anything. If your current process has a step where someone copies information from a chat into a sheet, that is the gap software should close.
Common gaps in cheap builds
A low price can hide missing parts. These gaps show up most often, and each one is easy to test in a demo.
A customer app with no operations dashboard. Dispatching then carries on by phone.
A rider tool that is only a reskinned customer app. Riders cannot see job details, earnings or payouts properly.
No proof of delivery. Disputes about whether a parcel arrived have no record to settle them.
No money records. Without fares, payouts and reconciliation in the system, finance goes back to spreadsheets.
Rates that need a developer. If changing a price means raising a support ticket, you will avoid changing prices.
Separate systems that do not share data. Information gets retyped, and mistakes follow.
No plan after launch. Without hosting, monitoring, backups and store updates, the platform decays quietly.
No clear ownership. Ask in writing what you receive, in what form and when.
A useful rule: ask the vendor to walk you through one delivery from booking to payout on real screens, not slides.
Frequently asked questions
What is a complete logistics platform?
It is a connected set of tools, a customer app for booking and tracking, a rider app for running deliveries and getting paid, an admin dashboard for your operations team, and a shared backend that keeps their records in step.
Do I need separate apps for customers and riders?
Customers and riders need different experiences, but they do not always need separate apps in the stores. In ServiceBlocks, the Launch package uses one shared mobile app with customer and rider experiences, and Launch Pro provides two separate apps.
Why does a logistics platform need a backend?
The backend stores orders, prices, payments and records, and connects the customer app, rider app and dashboard. Without it, each app holds its own version of events and your team has to reconcile them by hand.
What features should a delivery app have in Nigeria?
At a minimum, booking with a price shown first, in-app payment, rider assignment, live tracking, proof of delivery, rider earnings and payouts, and a dashboard for dispatch, pricing, support and reporting. Check that all of them work together in one system.
View the actual customer, rider and operations screens on ServiceBlocks Build / Logistics.