How to Build a Delivery Management Platform

A delivery management platform is not a delivery app with a database behind it. It is a system of record for every consignment, every status change, every rider action and every naira collected — and the applications on top are simply views onto that record. Teams that understand this build systems that survive growth. Teams that start by designing the customer screens usually rebuild within eighteen months.

This guide is written for founders, operations directors and product managers commissioning or overseeing a build. It sets out the data model to settle first, the architecture choices that matter, the order to build modules in, the integrations that must work, how to test for Nigerian conditions, and what the whole thing realistically costs.

What a delivery management platform actually contains

The critical design insight is that the first module owns the truth. Every other module reads from it and writes to it through defined interfaces. If the rider app maintains its own idea of a job's state, or the merchant portal caches statuses independently, you will spend your second year reconciling systems that disagree.

Before you build: decide whether you should

Building is the right choice under specific conditions, not as a default.

Build when:

• Your dispatch, pricing or settlement process genuinely differs from what products support
• Volume makes per-shipment or per-user subscription fees exceed an amortised build
• Merchants need API access to your system as a condition of contracts
• The platform is the product, because you intend to serve other logistics companies
• You need the data inside your own financial and operational systems

Do not build when:

• You handle fewer than roughly 100 jobs a day and no unusual process
• Nobody internally will own the system after launch
• The real problem is pricing, capacity or recruitment rather than information
• You are unwilling to fund continuous change after the first release

A pragmatic middle path exists: subscribe to a product now, insist on data export, and build later using a year of real operational data to inform the design. That is usually cheaper than building from assumptions.

Step 1: Model the job lifecycle and the data

An answer-ready summary: before any code, write down every state a consignment can be in, every event that moves it between states, every actor who can trigger those events, and every piece of money attached. Two to three weeks of this work prevents the most expensive category of rework.

The core entities

• Job or consignment: reference, sender, receiver, addresses with landmark text, item description, declared value, service level, price, payment method, COD amount expected
• Status event: job, status, timestamp, actor, device location, note, failure reason where applicable
• Run: date, rider or driver, vehicle, ordered list of jobs, planned and actual times
• Rider or driver: identity, contact, licence where relevant, assigned vehicle, active device, status
• Vehicle: plate, type, capacity, documents with expiry dates
• Proof record: job, recipient name, verification method, code or signature, photographs, time, location
• Money record: job, amount expected, amount collected, method, rider remittance, merchant payout, invoice reference
• Merchant or account: identity, rate card, credit terms, payout schedule, API credentials
• Zone: name, boundary or area list, and the rate table entries that reference it

Rules to settle at this stage

• Which status transitions are legal, and which are forbidden
• Who can reverse a status, and whether reversals are recorded as new events
• What happens to a job after the agreed number of failed attempts
• How a job is split or merged when a consignment contains multiple items
• How re-attempts are represented: new job, or new attempt on the same job
• How prices are versioned so a historical job keeps the rate it was quoted

That last point catches many teams. Rates change; historical jobs must not silently reprice when you edit a rate table.

Step 2: Choose architecture and technology

Backend. A single well-structured application is the right starting point for almost every delivery platform. Microservices add operational complexity that a first release does not need. Keep clear module boundaries inside one codebase so services can be separated later if volume demands it.

Database. A relational database suits this domain well, because jobs, statuses, money and runs are highly relational and reporting matters. Store status events as an append-only log rather than overwriting a status field, so you retain the full timeline.

Event handling. Status changes should publish events that notifications, reporting and integrations subscribe to. This keeps the core clean and makes adding a new notification channel a small change rather than a surgery.

Rider app. Cross-platform frameworks such as Flutter or React Native are usually the right choice, with an Android-first release. The app needs a local database, an outbound action queue and conflict handling for updates that arrive out of order.

Operations console and merchant portal. Responsive web applications. Dispatchers work on a desktop with many jobs visible; do not force them into a phone-sized layout.

Hosting. Managed cloud hosting with predictable billing, automated backups and a tested restore procedure. Budget hosting realistically: application-grade cloud hosting is materially more expensive than the shared hosting a marketing website uses.

Security. Role-based access, audit logging on every status and money change, encrypted data in transit and at rest, and strict controls on who can export customer data.

Step 3: Build order — what to ship first

1. Job service and status engine. Create a job, move it through statuses, record every event. Nothing else works without this.
2. Admin configuration. Zones, rates, statuses, failure reasons, users and roles, all editable without a developer.
3. Pricing engine. Quote a job from zone, weight band, service level and surcharges, with rate versioning.
4. Operations console, minimum version. Create jobs manually, view the board, assign to riders, handle exceptions.
5. Rider app, minimum version. Log in, see the run, update status, capture proof, record cash, work offline.
6. Notifications. Automatic messages on three or four statuses, to receiver and merchant.
7. Public tracking page. Lookup by reference, minimal personal data exposed.
8. Money and reconciliation. Rider shift statements, remittance matching, COD shortfall flags.
9. Customer booking on the website. Quote, book, pay.
10. Merchant portal and bulk upload. Then the merchant API.
11. Reporting. Operational and financial metrics management will actually use.
12. Extensions. Live map tracking, route sequencing, wallets, ratings, AI features.

Items one to eight constitute a usable operational system. Many teams try to build items nine and ten first because they are customer-facing, then discover they have no reliable status data to show.

Step 4: The integrations that must work

Two engineering rules save later pain. Make every inbound webhook idempotent, because providers retry and duplicate messages will otherwise duplicate payments or statuses. And record every outbound integration call with its response, so support can answer "was the message sent?" without guessing.

Step 5: Testing for Nigerian conditions

Standard test plans miss the conditions that actually break delivery platforms here. Test these explicitly.

• Rider app with data switched off for a full run, then reconnected
• Status updates arriving out of order after a long offline period
• App behaviour on a mid-range Android phone with low storage
• Battery consumption across a nine-hour shift with location enabled
• Photo upload on a slow connection, including partial failure
• Payment webhook arriving twice, or arriving late
• Payment webhook never arriving, with manual reconciliation available
• Descriptive addresses that geocode incorrectly or not at all
• Duplicate phone numbers across different customers
• Rider device lost or replaced mid-shift
• Bulk upload with 500 rows containing malformed data
• Concurrent assignment of the same job by two dispatchers
• Rate change applied while jobs are in flight
• SMS provider outage with automatic failover
• Server time zone handling for jobs spanning midnight

Run at least one full day of parallel operation where the platform and the existing process both record the same jobs, then compare every field.

Step 6: Pilot and rollout

1. Pick one hub and one team. Ten to fifteen riders is enough to surface most problems.
2. Run parallel for two weeks. Old process stays alive; compare records daily and log every discrepancy.
3. Fix the top ten issues. They will concentrate around offline behaviour, photo upload and one confusing screen.
4. Train in person. Twenty minutes per rider, in the language the team uses, with a printed one-page guide.
5. Appoint champions. Two riders and one dispatcher who help colleagues and feed problems back.
6. Close the old channel deliberately. Announce a date after which WhatsApp status reporting is no longer accepted, and hold it.
7. Expand hub by hub, not all at once.
8. Review at 30, 60 and 90 days against the baseline metrics recorded before the pilot.

What changes when building for Nigeria

Offline is a first-class requirement. The rider app must function fully without a network and reconcile cleanly afterwards. This is an architectural decision, not a feature to add later.

Addresses are descriptive. Store landmark text as a first-class field, allow pin-dropping, and save confirmed locations for reuse. Never make a structured address mandatory.

Cash is part of the data model. Amount expected and amount collected belong on the job. Systems that treat COD as an exception create reconciliation gaps that cost real money.

Costs in dollars must be capped. Mapping, messaging, model usage and cloud hosting are dollar-billed. Build usage monitoring and hard caps into the system from the start.

Devices are modest. Keep the rider app small, compress images on the device, and test on real mid-range hardware.

Power affects the hub. Scanning stations and office terminals need backup power, and the system should tolerate a hub going offline for an hour.

Data protection applies. Customer contact details, addresses, delivery photographs and rider location histories are personal data under the Nigeria Data Protection Act 2023. Build role-based access, retention periods and export controls into the platform, and confirm your obligations with the Nigeria Data Protection Commission or a qualified adviser.

Staff turnover is high. Onboarding, device deactivation and role changes must be self-service for an administrator, not developer tasks.

Team, timeline and indicative cost

A typical first-release team:

Indicative 2026 costs and timelines. Actual quotations vary with scope, vendor and the exchange rate.

Recurring: cloud hosting ₦150,000–₦800,000+ per year; maintenance typically 15–25% of build cost per year; mapping, SMS and WhatsApp usage by volume; payment gateway fees; app store fees, with the Apple Developer Program charged yearly (historically US$99 per year) and Google Play developer registration a one-time fee (historically US$25). Verify current platform fees before budgeting.

Reserve at least a quarter of the build budget for the twelve months after launch. A delivery platform that stops changing stops fitting the business.

Example (hypothetical): an eighteen-week first release

This is an illustrative scenario, not a client result.

A courier operating in Lagos and Ibadan with 40 riders decides to replace a subscription product that cannot support its merchant integrations.

• Weeks 1–3: lifecycle modelling, status and failure reason design, zone and rate model, data migration plan from the existing product.
• Weeks 4–8: job service, status engine, admin configuration and pricing engine. Internal demo with real historical jobs loaded.
• Weeks 7–12: operations console and rider app developed in parallel. Offline queue built first, not last.
• Weeks 11–14: notifications, public tracking page, payment integration with idempotent webhook handling.
• Weeks 13–16: money module — rider shift statements, remittance matching, COD shortfall flags, merchant payout runs.
• Weeks 15–17: Nigerian condition testing, parallel running at the Ibadan hub, fixes.
• Week 18: Ibadan cutover. Lagos follows four weeks later, hub by hub.
• After launch: merchant portal and API in the following quarter, informed by what the largest merchants actually ask for.

Indicative cost for this scope: ₦8,000,000–₦18,000,000, plus recurring hosting and usage. Baseline metrics recorded before the pilot: first-attempt success rate, drops per rider per day, COD shortfall percentage, status enquiries per 100 consignments, and days from delivery to merchant payout.

Mistakes to avoid

• Designing screens before the data model. The screens will be rebuilt; the data model rarely can be.
• Storing a single current status instead of an event log. You lose the timeline, the audit trail and any hope of useful analytics.
• Treating offline support as a later feature. Retrofitting it into a rider app is close to a rewrite.
• Allowing rate edits to reprice historical jobs. Version your rate tables from day one.
• Non-idempotent webhook handling. Duplicate payment or status messages will corrupt your money records.
• Hard-coding zones, rates and statuses. Operations must change these without a deployment.
• Building the merchant API before your own statuses are reliable. You will expose your data quality problems to your largest customers.
• No usage caps on dollar-billed services. Success becomes an unplanned expense.
• Big-bang rollout. Pilot one hub, hold the line on the cutover date, then expand.
• No named internal owner. Platforms without an owner drift into disuse within a year.

Conclusion

Building a delivery management platform succeeds or fails in the first three weeks, before code is written, when the job lifecycle, status list, failure reasons, pricing rules and money flow are settled. From there the build order is consistent: job service, configuration, pricing, console, rider app with offline support, notifications, tracking, then money. Test against Nigerian conditions explicitly, pilot one hub with a parallel run, close the old channel deliberately, and own your code and infrastructure from day one.

If you are planning a delivery platform and want the lifecycle and data model settled before development begins, Linestech builds logistics and delivery management systems for Nigerian companies, and can run that design phase as a standalone piece of work.

Frequently asked questions

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

Four to seven months for a usable core covering jobs, dispatch, a rider app and tracking, assuming decisions are made promptly. Six to ten months once merchant portals, APIs and full reconciliation are included. The most common cause of overrun is not engineering; it is unresolved business rules about pricing, statuses and settlement.

What is the difference between a delivery app and a delivery management platform?

A delivery app is a customer or rider interface. A platform is the system of record beneath it: jobs, statuses, pricing, dispatch, money and reporting, with apps and portals as views onto that record. You can have apps without a platform, but you will not be able to report, reconcile or integrate reliably.

Should we build multi-tenant so we can sell it to other companies later?

Only if that is an actual business plan with a named first external customer. Multi-tenancy adds meaningful complexity to authentication, configuration, data isolation and support. A well-structured single-tenant system can be converted later, and doing so with real operational knowledge usually produces a better product than speculating upfront.

Can we start with the rider app and add the platform later?

Not sensibly. The rider app needs somewhere to send statuses, proof and cash records. What you can do is build a minimal job service and console alongside the rider app, deliberately excluding customer and merchant layers from the first release.

How do we migrate from an existing system without stopping operations?

Freeze new jobs in the old system at a chosen cut-off, run open jobs to completion there while new jobs start in the new platform, and import historical data read-only for reference and reporting. Plan the cutover for your quietest day, not a Monday or a festive peak.

What should we do about live map tracking?

Leave it out of the first release. It requires continuous location transmission, which increases rider battery and data consumption, and it rarely reduces complaints as much as accurate status notifications and realistic windows. Add it later for the services where customers are genuinely waiting.

Who should own the code and infrastructure?

Your company, in writing, before development starts. That means the source repository, the cloud accounts, the app store accounts, the domain and the payment gateway accounts all in your company's name, with a documented handover. This is the single most important commercial clause in a platform contract.

How much should we budget after launch?

At least 15–25% of the build cost per year for maintenance, plus hosting and usage, plus a change budget. Delivery platforms evolve constantly as merchants ask for integrations, operations change and volume grows. A platform with no change budget becomes the thing your team works around within eighteen months.

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
• Apple Developer Program
• Google Play Console
• PostgreSQL documentation
• AWS Architecture Center
• Cloudflare Learning Center