Dispatch and proof of delivery app for a regional logistics company

The situation

Picture a regional logistics company in Maharashtra delivering industrial goods and building materials for manufacturers and distributors. It runs four depots, around 60 vehicles and a mix of permanent and contract drivers, and makes 600 to 800 deliveries a day to factories, dealers and construction sites.

Deliveries still run on paper. Dispatchers plan routes from experience and a whiteboard. Drivers carry printed delivery challans, get them signed and bring them back in the evening, if they don't get lost or rained on. Customers call the depot to ask where their goods are, and the depot calls the driver. Billing waits for signed challans to be scanned, so cash collection runs days behind delivery. When a customer disputes a short delivery, there's no photo and often no clear record of who signed.

The company needs a simple dispatch console for the depot, a driver app that works on cheap phones and in places with no signal, and a clean link to its ERP so a confirmed delivery releases the invoice the same day.

Signs this blueprint fits you

• Signed delivery notes come back hours or days after the delivery.
• Customers regularly call to ask where their goods are.
• Invoices wait for paperwork, and delivery disputes take weeks to settle.
• Route planning depends on one or two experienced dispatchers.

What we'd build

• A dispatch console (React web app) where depot staff import the day's orders, plan routes with suggested stop order, assign vehicles and track progress live.
• A driver app (Flutter, Android first) that downloads the route before departure, works fully offline, and captures signatures, photos, OTPs, GPS and exceptions at each stop.
• A delivery API (Node.js and PostgreSQL) that holds orders, routes and proof of delivery, and syncs with the ERP.
• Customer notifications: out-for-delivery messages with a live tracking link, and a delivery note with photos after each drop.
• Exception handling for short, damaged, refused and partial deliveries, with reasons that flow back to the ERP.

How the pieces fit

Offline first

Drivers deliver to basements, rural plants and highway sites where signal comes and goes. The app stores the full route on the phone before leaving the depot and records every proof of delivery locally, with the device time and GPS. Data syncs in the background whenever signal returns, and conflicts are resolved on the server. A delivery is never lost because the network was down.

Routes that suit your operation

We use Google Maps Platform for geocoding and travel times, and a route optimiser that respects your constraints: vehicle capacity, delivery time windows, customers who only accept goods before noon. Dispatchers always have the final word and can drag stops between routes.

Proof that settles disputes

Each delivery records who received it, when and where, with photos and a signature or OTP. Partial and damaged deliveries are captured at the stop with a reason, so the invoice reflects what was actually delivered and disputes can be answered with evidence.

ERP integration

Orders flow in from the ERP each morning. Delivered quantities, exceptions and POD links flow back as soon as a delivery syncs, so the ERP can raise or release the invoice the same day.

One delivery, end to end

Here is a delivery to a hardware dealer's basement store, where there is no mobile signal.

What dispatch and drivers would see

Dispatchers see every route's progress in one place, with stops colour-coded and exceptions at the top. Drivers see one stop at a time with large buttons, simple steps and a clear indication of whether their data has synced. The app is designed for low-cost Android phones, bright sunlight and gloves.

Data and integrations

Delivery plan

We start by riding along with drivers for a few days, because the details of how deliveries really happen, such as who signs at a construction site or how cash on delivery is handled, decide whether the app gets used. Field testing covers basements, highway sites and the cheapest phones your drivers use before the pilot depot goes live.

The team

What changes the effort

• Route optimisation. Suggested stop order is included. Full multi-depot optimisation with time windows and capacity is a larger piece.
• Cash on delivery. Collecting and reconciling cash or UPI at the door adds a payment flow.
• ERP access. A documented API is quick; older ERPs need exports or a staging database.
• iOS. Android only is the baseline for drivers. iOS adds testing, though Flutter keeps it to one codebase.
• Third-party fleets. Contract carriers using their own apps need a separate integration.

Risks and how we'd handle them

What we'd measure

Build or buy?

Ready-made delivery management apps work well for parcel and e-commerce operations with standard workflows. A custom system makes sense when your deliveries are industrial and messy: partial loads, multiple invoices per stop, site receivers who change daily, ERP integration that has to be exact, and drivers who need the app in their own language on cheap phones. Owning the system also means no per-driver fees as the fleet grows.

Questions we'd ask on the first call

• How many depots, vehicles and deliveries a day?
• Which ERP holds orders and invoices, and how can we read from it?
• What exceptions happen most: short, damaged, refused, rescheduled?
• Do drivers collect payments at the door?
• What phones do your drivers use, and which languages do they read?

FAQ

Will it work on cheap Android phones?

Yes. We test on low-end devices from the start, keep the app small, and compress photos before upload.

Can customers track deliveries?

Customers get a link with live ETA when the driver is on the way, and a delivery note with photos afterwards.

Can we use it for contract drivers?

Yes. Contract drivers log in with a phone number and OTP, and only see the routes assigned to them.