Last-Mile Delivery Software for Couriers: Problems Onfleet and Spreadsheets Cannot Fix

Why last-mile delivery software makes or breaks a courier operator

It is 6:40 am at your busiest depot. Fourteen routes need to roll by 8:00. One driver texted the WhatsApp group at 6:12 that he is sick, so your dispatcher is re-cutting his 62 stops in a Google Sheet, then reassigning tasks in Onfleet one at a time while the group chat fills with drivers asking where their manifests are. Meanwhile your largest retail client has emailed asking why yesterday's proof of delivery photos are missing from three big-and-bulky orders, and the answer is that one driver's app crashed and the photos live on his phone.

This is the standard stack for a regional courier at scale: Onfleet for dispatch and tracking, spreadsheets for route planning, driver pay, and client billing, and a group chat as the exception management system. Each piece works. The seams between them are where the money leaks. A dispatcher spends 90 minutes every morning pre-sorting orders that auto-dispatch cannot sequence correctly. A payroll clerk spends every Friday reconciling task exports against a pay sheet. An operations manager spends three days a month building invoices in Excel and still misses redelivery fees. At 2,000 stops a day, those seams cost more than the software does.

If you are reading this with a budget between $100,000 and $400,000, you are past the point where another Onfleet tier or another Zapier connection fixes anything. The question is which problems a custom platform actually solves, what it costs, and when buying is still the smarter move.

Auto-dispatch that ignores how your contracts actually work

Say your book of business is mixed: same-day medical runs that need refrigerated vans, next-day furniture that needs two-person crews, and scheduled retail deliveries with two-hour windows promised to the end customer. Onfleet's auto-dispatch optimizes within a team and treats tasks as interchangeable. It has no way to encode "this order requires a liftgate," "this driver is not certified for alcohol," or "this client's SLA pays a penalty after 6:00 pm." So your planners hold those rules in their heads and a spreadsheet, pre-sorting orders into teams before Onfleet ever sees them. That is the 90-minute morning ritual, repeated in every market you open.

A custom build moves those rules into the routing layer itself. Orders carry attributes: weight, cube, temperature class, crew size, certification requirements, contracted window, SLA tier. Vehicles and drivers carry profiles: capacity, equipment, skills, shift limits. A solver, usually built on Google OR-Tools or a commercial routing engine rather than written from scratch, produces routes that satisfy all of it at once. When a driver calls out at 6:12 am, a dispatcher reflows the affected routes in one action instead of sixty. The constraint model is yours, so a new contract with odd rules becomes a configuration change, not a new spreadsheet.

Order ingestion is a part-time job per client

Every new contract arrives with its own order format. One client emails a CSV at 5:00 am with addresses jammed into a single column. Another exports from Shopify. A national shipper wants EDI. Someone on your team maps columns, fixes addresses, uploads to Onfleet, and hopes nothing duplicated. When the 5:00 am email arrives at 6:15 instead, the whole morning slides. Onfleet has an API, but connecting it to each client's format means you are already building and maintaining middleware, just badly, through Zapier connections that fail silently.

The custom answer is an ingestion layer with an adapter per client: watched SFTP folders, Shopify and WooCommerce webhooks, EDI 204 for retail shippers, a plain REST endpoint for the technical ones. Every order is validated, geocoded, and deduplicated on entry. Anything that fails validation lands in an exceptions queue with an alert to a named person instead of disappearing. Onboarding a new client becomes a two-day adapter task instead of a permanent line in someone's job description.

Proof of delivery scattered across three systems

A client disputes an $1,800 sofa delivery. The photo is in Onfleet, the signature capture failed, and the only record of the customer saying "leave it in the garage" is a message in the driver group chat from three weeks ago. Your dispatcher spends 45 minutes assembling a defense, the evidence is incomplete, and you eat the claim. Multiply that across every contract and the real loss is not the sofas, it is the dispatcher hours and the client's growing doubt.

A custom platform treats the delivery event as one record: photos, GPS coordinates checked against the delivery pin, timestamp, signature or ID scan, and your own exception codes. That record attaches to the order permanently and is visible to the client in their portal the moment the stop completes, so many disputes never get filed. When one does, the defense is a two-minute lookup, not an archaeology project across Onfleet, camera rolls, and chat history.

Driver settlement and the Friday pay fight

Most couriers at this scale pay drivers per stop with tiers and adjustments: attempt versus completion, redelivery deductions, weekend premiums, density incentives. None of that lives in Onfleet, so it lives in a spreadsheet fed by CSV exports and lookups. Drivers dispute counts in the group chat every Friday, the payroll clerk arbitrates from the same messy data, and your 1099 contractors quietly churn to whoever pays them legibly.

Because a custom platform already records every delivery event, settlement becomes arithmetic on data you trust. A rating engine computes each driver's earnings as stops complete. The driver app shows running pay for the day, per stop, with a dispute button that routes to a workflow instead of a group chat. Weekly statements generate themselves and export to payroll. This is the module operators underestimate most and value most: pay transparency is a retention tool in a market where drivers pick contracts based on trust.

Billing that runs three days late and leaks accessorials

Client billing has the same shape as driver pay, pointed the other direction. Each contract has a rate card: per stop by zone, fuel surcharge, wait time, redelivery fees, weekend premiums. Building invoices in Excel from Onfleet exports takes days and systematically misses accessorial charges, because the person invoicing cannot see which stops had a second attempt or 40 minutes of dock wait. Operators routinely discover entire categories of billable work they never invoiced.

The custom fix is pricing every event at the moment it closes. The same rating engine that computes driver pay applies the client's rate card to the completed stop, accessorials included, and the invoice becomes a report, not a project. Line items sync to QuickBooks or Xero. Just as important, you see margin per route, per client, per day, which is the number that tells you which contract to renegotiate, and today you see it quarterly at best.

What custom last-mile delivery software costs and how long it takes

Across 2,000+ delivered projects at Digital Heroes, a focused first release in this category typically runs $60,000 to $130,000 and ships in 12 to 16 weeks. That usually means the ingestion layer, a dispatch board, a driver app with proof of delivery, and one money module, either settlement or billing, wired to your accounting system. Full platforms, with constraint-based routing, client portals, branded tracking pages, both money modules, and analytics, run $150,000 to $400,000 phased over 6 to 12 months.

What pushes price up in this category specifically: the driver app, because offline-first operation, background GPS, and battery discipline on cheap Android hardware are genuinely hard; routing depth, since every constraint type you encode adds solver and testing work; the number of client integrations at launch, EDI being the heaviest; live tracking scale, because thousands of concurrent GPS pings need real infrastructure; and settlement complexity if your pay rules have accumulated years of exceptions. The cheapest scope decision you can make is launching with two client adapters instead of ten and adding the rest as contracts demand.

Build vs buy: when Onfleet is still the right answer

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, which run roughly $550 to $1,265 per 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.

The signals it is time to build are concrete. You employ the equivalent of one or two full-time people doing manual glue: pre-sorting routes, re-keying orders, reconciling pay, building invoices. You have lost at least one contract bid because a shipper wanted branded tracking, a client portal, or EDI. Your fleet has constraints the optimizer cannot express, so its output is a suggestion your planners rework by hand. Driver churn traces back to pay disputes. Hit three of those and the build pays for itself in headcount and won contracts before it is a year old. Our position: at multi-market scale, delivery software is what enterprise shippers are actually buying when they pick a courier, and you cannot differentiate on a tool every competitor can also rent for $1,265 a month.

How to choose a developer for last-mile delivery software

First, 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, failed attempt, redelivery, 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 you a demo that collapses in month two.

Second, ask for integration receipts, not claims. You want evidence of shipped work against Shopify or WooCommerce webhooks, EDI 204 and 214 for retail shippers, telematics platforms like Samsara or Geotab, and QuickBooks or Xero. Ask to watch an ingestion pipeline handle a malformed file, because the failure path is the product.

Third, interrogate their mobile discipline. Ask exactly what happens when a driver captures proof of delivery in an underground parking garage with no signal, and what the app does to a phone battery over a ten-hour shift. Teams that have not shipped an offline-first field app will not have crisp answers, and drivers will not forgive them.

Fourth, if your freight includes alcohol, pharmacy, or medical work, test their compliance fluency: 21+ ID verification at the door, chain-of-custody records, cold-chain logging, and sane retention rules for driver location data. These requirements shape the data model from day one, and retrofitting them costs more than building them in.