Delivery management software development that reconciles every drop

The short answer

Delivery management software development means building the system that carries an order from intake to a confirmed, paid drop: a dispatch console to assign jobs, a driver app for navigation and status updates, live tracking for the recipient, proof of delivery by photo, signature or one-time PIN, route planning for multi-drop runs, and cash on delivery reconciliation that matches what drivers collected against what reached the bank. Growth Informer Software Services builds these as custom web and mobile software from Kampala, Uganda, with a fixed quote before work starts and the source code and data owned by you.

A first release with the web dispatch console, a mobile web driver screen for status updates and proof of delivery photos, and the end-of-shift cash-up starts . A native Android driver app, which you need for live tracking with the phone screen off and for scanning without signal, is quoted on top, typically . Route optimisation, customer tracking links and merchant portals follow in later phases. If you run a handful of vans on simple routes and customers pay online, a subscription tool is usually the better first step.

What we build into a delivery management system

Logistics software development succeeds or fails on the unglamorous parts: the failed delivery, the driver with no signal, the cash that never gets banked. We scope those first and the dashboards last.

Dispatch console

The core of any dispatch software development project is a live board of every job by status: unassigned, assigned, picked up, in transit, delivered, failed and returned. Orders arrive from your online store, an API, a spreadsheet upload or a call centre form. Dispatchers assign by hand or let rules assign by zone, vehicle capacity, driver shift and distance, and a timer flags any job at risk of missing its promised window while there is still time to reassign it.

Driver app

• Offline-first job list: scans, photos and signatures save on the phone and sync when signal returns
• If dispatch reassigns a job while the driver is offline, the app shows the change on sync and blocks completing a job that has moved
• One-tap handoff to the driver's preferred navigation app
• Barcode or QR scanning at pickup, hub and drop, so the wrong parcel cannot be marked delivered
• A warning when a drop is confirmed too far from the delivery pin
• Failed delivery reasons with photo evidence and a rescheduling queue

Live tracking that survives app review

Continuous tracking has to be designed around platform rules, not bolted on. On Android 14 and later, a tracking service must declare the location foreground service type and its matching permission, and it shows a notification while it runs. We start it when the driver opens a shift with the app on screen, which Android treats as foreground location use. That avoids requesting background location, which on Google Play means a permissions declaration form, a video demonstration and a prominent in-app disclosure. On iOS, Apple's review guideline 2.5.4 limits background modes to their intended purposes and guideline 5.1.5 requires location use to be directly relevant to the app, so the reason for tracking has to be visible in the product itself.

Customer notifications

The recipient gets a tracking link with an estimated arrival time and messages at the milestones that cut "where is my parcel" calls. WhatsApp updates go out as utility template messages, which Meta bills per delivered message at a rate set by the recipient's country, except inside the 24-hour window after the customer last messaged you, when utility templates are free. We design the flow to use that window, for example by asking the customer to reply to confirm a delivery slot, and fall back to SMS for recipients who do not use WhatsApp.

Proof of delivery

Photo, signature, recipient name or a one-time PIN sent to the recipient, each stamped with the time and GPS point and stored against the job. When a customer disputes a delivery, your team opens the job record and sees the evidence instead of phoning the driver.

Route planning

Multi-drop sequencing that respects time windows, vehicle capacity and where each driver starts. We connect to an established routing engine rather than writing optimisation maths from scratch, which keeps the build cost down. The trade-off is a usage-based bill per routing request, which we estimate from your daily volume before you commit.

Reporting

First-attempt success rate comes first, because every failed attempt is a drop you pay for twice. Alongside it: on-time rate against the promised window, cost per drop from driver pay and fuel, returns by merchant and COD variance by driver, all filterable by zone, client and vehicle.

Cash on delivery reconciliation, done like a ledger

Wherever customers still pay on the doorstep, cash on delivery is where margin quietly disappears. A driver collects cash on thirty drops, takes Mobile Money on two more, pays for fuel out of the bag and banks the rest the next morning. Without a system, finance reconciles that from a notebook and a WhatsApp thread, days after anyone can remember what happened.

• Every COD job carries an expected amount, locked at dispatch so it cannot be edited in the van
• The driver records how each payment arrived: cash, Mobile Money, card or bank transfer, with the reference captured
• Mobile Money collections are confirmed by the provider's callback, not a screenshot, through our Mobile Money integration work
• Fuel and other spending from the cash bag is logged with a receipt photo, so it reduces the cash expected instead of showing up as a shortage
• End-of-shift cash-up compares expected, declared and banked amounts and flags every variance by driver
• Each driver carries a running balance, so a shortfall rolls forward instead of vanishing
• Couriers serving merchants get remittance statements net of delivery fees and returns, ready to pay out

Here is how one shift closes. A driver leaves with 42 COD jobs, delivers 38 and brings 4 back. The system now expects payment on 38 jobs, not 42. The driver declares cash on 35 and Mobile Money on 3, so the cash-up checks the 35 cash amounts against the handover and looks for 3 matching provider confirmations. If one confirmation never arrived, that job shows as a variance against that driver before the shift is closed, not at month end.

We build this on double-entry records: every collection has a matching entry, and nothing is deleted, only reversed with a reason. It is the same discipline behind Moyo Pay, our own dual-currency wallet running on a double-entry ledger with Mobile Money and USSD. During scoping we walk your finance lead through the entries each collection creates, so the rules are agreed before any code is written.

Custom build or off-the-shelf delivery software?

Plenty of operators should not build. Subscription delivery tools handle standard last-mile work well and can be running within days. Courier software development only pays back when your operation has outgrown them.

Stay with an off-the-shelf tool if

• You run a small fleet on simple same-day routes
• Customers pay online, so there is no cash to reconcile
• The tool already connects to your store and accounting package
• You are still proving demand in a new city

Build custom if

• Per-driver or per-task fees now cost you more each year than owning the software would
• You bill many merchants with different rate cards, zones and COD remittance terms
• You run hub-and-spoke or multi-leg deliveries that a last-mile tool cannot model
• Dispatch has to talk to your own ERP, warehouse or ecommerce stack in both directions
• Drivers hand over cash and Mobile Money that the tool cannot reconcile per shift
• You want delivery data and customer relationships on systems you own

Two related builds are worth separating early. If your problem is vehicles rather than jobs, meaning fuel, maintenance, trackers and insurance, that is fleet management software, and many operators need both sharing one driver record. If you want an on-demand marketplace where customers book independent riders, the scope and economics look more like building an app like Uber than a dispatch system.

What delivery and logistics software costs

We quote a fixed price per phase after scoping, so you know the number before any work starts. The ranges below show where delivery and courier components typically land; your figure depends on how many apps, integrations and payment flows are in scope. For a rough figure before you message us, try the software project cost calculator.

Payment follows our 50/25/25 plan across the build, and you own the source code and the data. Third-party running costs, such as routing requests, WhatsApp and SMS messages and cloud hosting, grow with your volume. We estimate them in the quote and recommend they sit on accounts in your company's name.

A phasing that keeps risk low

Phase one is dispatch, the driver app, proof of delivery and the cash-up, so jobs stop living in WhatsApp groups and cash stops living in notebooks. Phase two adds route optimisation and customer tracking links. Phase three adds merchant portals, rate cards and COD remittance. If you also sell online, we connect dispatch to your ecommerce platform so paid orders flow straight onto the job board and delivery status flows back to the customer's order.

What we bring to a delivery build

A delivery system is three hard problems behind one interface: money that has to reconcile to the last payment, order records that many people change at once, and apps that staff depend on every working hour. We run our own live software in each of those areas, and during scoping we tell you plainly which parts of your build are new ground.

• 37 live website and app builds you can inspect in our portfolio
• Moyo Pay, our own dual-currency wallet on a double-entry ledger with Mobile Money and USSD, the pattern behind the cash-up described above
• Growth Informer Business, our own live cloud POS, inventory and business platform, where orders and stock records already run in production
• Karibu, our travel SaaS
• More than a hundred thousand US dollars of client ad spend managed, so we build knowing that a delivery promise made in an ad has to be kept by dispatch
• A fixed quote before work starts, a 50/25/25 payment plan, and the code and data in your name

Delivery problems surface in the morning dispatch rush, so support hours matter. East Africa Time is UTC+3 all year with no daylight saving: the same clock as Saudi Arabia, an hour behind the UAE, two to three hours ahead of the UK depending on the season, and seven to eight hours ahead of the US East Coast. For operators in the Gulf and Europe, our working day overlaps most of yours; for US operators, it covers the start of yours.

Frequently asked questions

How much does delivery management software development cost?

A first release with the web dispatch console, a mobile web driver screen, proof of delivery and the cash-up starts . A native Android driver app for live tracking and offline scanning is typically on top, and apps on both Android and iOS, route optimisation and merchant remittance move the figure up again. You get a fixed quote per phase before any work starts.

Can the driver app work without mobile signal?

Yes. Jobs, scans, photos and signatures save on the phone with the time and location of capture, then sync when the connection returns. If a dispatcher reassigns a job while the driver is offline, the app shows the change on sync and will not let the driver complete a job that has moved.

Will a driver app with live tracking pass Google Play and App Store review?

It can, if tracking is designed in from the start. On Android we run tracking as a location foreground service started when the driver opens a shift, which avoids the extra Google Play declaration and video demonstration that background location requires. On iOS, Apple only allows background location for features that genuinely need it, so the tracking purpose has to be clear in the app. We plan for both during scoping, before any code is written.

Do we have to replace our ecommerce store or ERP?

Usually not. We connect dispatch to the systems you already run through their APIs or webhooks, so orders arrive automatically and delivery status flows back. We only suggest replacing a system when it cannot share data at all.

Who owns the software and the delivery data?

You do. You own the source code and the data, and we recommend hosting, maps and messaging accounts are held in your company's name, so you are never locked in to us.