Last-Mile Delivery Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the full platform first release keep collapsing?

Every courier at this scale has the same list: constraint based routing, a driver app, client portals, branded tracking, driver settlement, client billing and analytics. All of it is real pain and all of it goes into release one. Five months later the driver app is half finished, the routing solver is being tuned against constraints nobody has finalised, and dispatch is still running the morning off a Google Sheet.

What makes this specific to last mile is that the driver app is the hardest component and the one whose quality determines whether anything else gets used. Offline first operation, background location, battery discipline on inexpensive Android hardware and a sync model that survives a ten hour shift are genuinely difficult engineering. Teams that treat the app as a thin client on top of an application programming interface discover this in month three, and by then the routing work has consumed the contingency.

The sequence that works is order ingestion, a dispatch board, the driver app with proof of delivery, and exactly one money module, either settlement or billing, wired to your accounting system. Constraint based routing, portals and the second money module come next. That is a coherent first cut because it produces a trustworthy delivery event record, and both money modules are arithmetic on that record. Build the record first and the rest gets easier. Build the routing first and you are optimising against data you do not yet capture.

What goes wrong when you migrate tasks, addresses and pay history?

Three migrations look routine and are not. Historic tasks and proof of delivery from Onfleet are the first. Pulling several years of task records sounds prudent, and it produces a large archive whose photos are hosted somewhere you do not control and whose exception reasons come from a generic list rather than from your codes. Treat it as an archive for dispute defence, exported and stored on your own infrastructure, not as operational history your new reporting computes against. Mixing the two produces analytics where last year's exception categories do not map to this year's, and nobody trusts a trend line that changes definition halfway through.

Address data is the second and it is the one that bites operationally. Client address files carry apartment numbers in the street line, suite numbers missing entirely, and delivery notes embedded in the address string. Geocoding that at scale produces pins that are plausibly wrong, which is worse than obviously wrong, because a route sequences correctly and a driver arrives at the building next door.

Driver pay history is the third. Rates have accumulated exceptions over years, some agreed verbally, some applied only to particular depots. Importing the spreadsheet without reconciling it means your first settlement run disagrees with drivers' expectations, and driver trust is not something you get a second attempt at.

The fix in each case is verification rather than volume. Geocode and review the addresses for your top clients before go live, with a human checking a sample against satellite imagery. Reconcile pay rules with each depot manager and write them down before anyone codes a rating engine. And run the first two settlement periods in parallel with the old spreadsheet, publishing both, so a discrepancy is a conversation rather than a dispute.

Why do client and accounting integrations break after launch?

Client order feeds break constantly and quietly, because they are somebody else's system and you are not their customer. A client changes their export template, adds a column, renames a header, or moves their nightly job by an hour. A Shopify store installs an app that changes the order payload. None of this is announced.

The failure that hurts is silent partial ingestion: eighty of a hundred orders load, twenty fail validation, and if failures go to a log rather than to a person, twenty stops do not get delivered and you find out from the client. Every ingestion adapter needs an exceptions queue with an alert to a named person and a hard rule that a file which does not fully validate raises an alarm rather than partially loading. Also alert on absence: if a client's file has not arrived by its usual time, that is an event, because a missing file looks identical to a quiet morning.

Accounting integrations break differently, usually on the chart of accounts. Someone in finance renames or restructures an account and the sync starts posting to the wrong place or failing. Reconcile invoice totals against the accounting system daily rather than at month end, and treat any difference as an exception with an owner.

Telematics integrations tend to be the most stable, but they carry a trap: two sources of location truth. Decide explicitly whether the driver app or the vehicle is authoritative for a delivery event, because a proof of delivery pin that disagrees with the telematics track will eventually come up in a dispute.

What happens when evidence and freight specific requirements are not covered?

Two gaps convert into money. The first is the delivery event as evidence. It needs to be one record: photos, coordinates checked against the delivery pin, timestamp, signature or identity scan, and your own exception codes, attached permanently to the order and visible to the client. Systems that scatter these across a task record, a photo service and a chat message cannot defend a claim, and each undefended claim costs both the goods and the dispatcher hours spent losing the argument.

The second is freight specific requirements, which shape the data model and are expensive to add later. Alcohol delivery involves age verification at the door in most states. Medical and pharmacy work brings chain of custody records with their own retention expectations. Temperature sensitive goods need logged cold chain evidence tied to the stop rather than to the vehicle shift. Driver location data carries privacy obligations, which means retention windows and access rules should be designed in rather than bolted on after a client's security questionnaire asks about them.

Both belong in the first release if the freight is already in your book. Retrofitting identity verification into a completed delivery flow means revisiting the app, the event model, the client portal and the retention policy at once, which is close to rebuilding the thing you just shipped.

Should you build custom or configure what you already own?

Onfleet earns its fee when you run a single market with one service type, standard proof of delivery, and volume that fits its published plans, roughly five hundred and fifty to one thousand two hundred and sixty five dollars a month with task limits. If your dispatchers are not maintaining shadow spreadsheets and your clients are not asking for portals you cannot provide, keep it and spend the budget on vans. That is genuinely the right answer for a large share of the operators who call us.

There is also a middle path worth taking seriously. If your only real problem is order ingestion, building an ingestion and normalisation layer that feeds Onfleet costs a fraction of a platform and removes the part time job per client. Plenty of couriers should do exactly that and stop.

Build when the signals stack up: you employ the equivalent of one or two full time people doing manual glue, pre sorting routes, re keying orders, reconciling pay and building invoices; you have lost a contract bid because a shipper wanted branded tracking, a portal or electronic data interchange; your fleet has constraints the optimiser cannot express so its output is a suggestion planners rework by hand; or driver churn traces back to pay disputes.

How do hidden costs get into the quote?

The driver app is the first and largest. Offline first operation, background location and battery discipline on cheap hardware are real engineering, and a quote that treats the app as a screen set is quoting a fraction of it. Ask specifically what happens when a driver captures proof of delivery with no signal and the phone stays offline for two hours, and what the app does to a battery across a ten hour shift.

Second, routing depth. Every constraint type you encode is solver work plus test cases, so twelve constraint types cost considerably more than three. Third, the number of client adapters at launch, with electronic data interchange the heaviest. Launching with two adapters instead of ten is the cheapest scope decision available to you. Fourth, live tracking at scale, because thousands of concurrent location updates need infrastructure rather than a socket. Fifth, settlement complexity if your pay rules have accumulated years of exceptions.

Ask what is included per additional client adapter and per additional routing constraint, in writing, before contract.

What separates a build that works from one that fails here?

Make them whiteboard the domain model before you sign anything. Orders, stops, routes, manifests and delivery events are different objects with different lifecycles, and exception states such as failed attempt, redelivery and return to depot drive everything downstream in pay and billing. A developer who models a delivery as one row with a status column will build a demonstration that looks excellent and collapses in month two when the first redelivery has to be priced differently for the client and the driver.

Ask for integration receipts rather than claims. Shipped work against Shopify or WooCommerce webhooks, electronic data interchange 204 and 214 for retail shippers, telematics platforms, and QuickBooks or Xero. Then ask to watch an ingestion pipeline handle a malformed file, because the failure path is the product.

The builds that work price every event at the moment it closes, so settlement and invoicing are reports rather than projects, and drivers see running pay per stop with a dispute button that routes to a workflow instead of a group chat. The builds that fail deliver a beautiful dispatch board, an app that loses captures underground, and an invoice process that still runs three days late in Excel, at which point the operator has bought a more expensive version of the problem they started with.