Late drop-offs, missed time slots, customers ringing to ask where their order is, and a dispatcher re-keying the same address into three different screens. If that sounds like your morning, the software you’re running may be part of the problem rather than the fix. A lot of off-the-shelf delivery platforms expect you to bend your process around the tool. I build delivery management and dispatch systems the other way round, around how your operation already runs.
There’s no monthly per-user, per-vehicle or per-stop fee, because you own what I build. The systems start narrow, cover the jobs that hurt most, and grow as the business does. You get the source code, and the person who built it is the one you call when something needs changing.
Where off-the-shelf delivery software gets in the way
For a single region, standard dispatch rules and modest daily volume, a platform like Onfleet, Shipday or OptimoRoute is often the right call, and I’ll say so. The trouble starts when the operation has edges the tool wasn’t built for:
- Pricing scales the wrong way. Per-driver, per-vehicle and per-stop models look cheap on the first invoice and climb with every delivery and van you add, before overage fees, API charges and add-ons.
- Business rules don’t fit. SaaS dispatch is usually nearest available driver or first in, first out. Multi-tier driver commission, regional pricing, holding high-value orders for manual approval, or tendering overflow to the cheapest compliant carrier usually can’t be configured without the vendor’s engineering time, if at all.
- Integrations are shallow. Orders arrive from Shopify ten minutes late or get imported twice, sync runs one way only, and getting completed deliveries back into your billing system means someone exporting a spreadsheet.
- The audit trail is the wrong shape. Most tools capture a final proof of delivery. Few capture a full chain of custody, with handler IDs at every hand-off and temperature readings along the way, so food and pharmacy operators patch the gaps by hand.
- Route editing is rigid. Several platforms make it hard to amend a generated route or handle awkward time windows, so dispatchers fight the optimiser instead of using it.
- Reporting is generic. Standard dashboards rarely show the numbers you manage by, and custom reports mean a support ticket.
- Your data is hard to leave with. Exporting historical delivery records and driver performance is often restricted, and a price rise or a vendor pivot is out of your hands.
So people build workarounds: a spreadsheet alongside the platform, manual re-keying between systems, a process only one person fully understands. You end up paying for modules you never touch and still missing the one thing you needed.
What I build instead
I start by watching how your deliveries happen, from order intake through to a signed proof of delivery, then build software that fits that. You pay once for the build, plus an optional hosting plan, instead of a fee that never stops.
The system connects to the tools you already run, and the integrations are designed for the parts that usually go wrong: address geocoding where order systems hold no coordinates, schema mapping so mismatched order formats line up, idempotency keys and retries so an order is never imported twice or silently dropped, and two-way sync so a completed delivery flows back to billing without anyone re-typing it.
Your dispatch rules become the system’s rules: skills-based allocation, capacity and weight limits, time windows, priority overrides for urgent jobs and manual review for high-value orders.
UK GDPR is designed in from the start, with role-based access, an audit trail of who assigned and changed what, sensible retention periods and right-to-erasure handling. Hosting can sit in a UK region where data residency matters. And the architecture leaves room: route optimisation, a customer tracking portal or multi-carrier handling can land in a later phase rather than holding up go-live.
What goes into a delivery system
The modules are shaped around your operation rather than shipped as a fixed product. A typical build draws from:
- Order management: intake by manual entry, CSV import or API, with address validation, a clean queue and delivery-window handling
- Dispatch board: assigning drops to drivers and vehicles by location, capacity and skill, by drag-to-assign or by rules
- Route planning and optimisation: multi-stop sequencing that accounts for traffic, vehicle capacity, weight and size limits, and time windows
- Driver app: the day’s jobs, turn-by-turn navigation, and offline-tolerant working for patchy signal, delivered as a web app that installs on the phone
- Proof of delivery: signatures, photos, barcode scans and notes captured against each stop, with timestamps that hold up to scrutiny
- Chain of custody: handler IDs at each hand-off and temperature readings where the load needs them
- Live tracking: a dispatcher dashboard showing every delivery on a map and flagging the ones running late
- Customer notifications: SMS and email at confirmed, on-the-way and delivered, with real ETAs and a branded tracking link
- Failed-delivery handling: capturing the reason, evidence and reattempt, so exceptions aren’t lost
- Carrier integration: labels and tracking through DPD, Royal Mail or DHL for the parcels your own vans don’t carry
- Reporting: on-time percentage, cost per delivery, driver utilisation and mileage, built around the numbers you manage by
- Role-based access: dispatchers, drivers and managers each see what they should
Later phases tend to add multi-carrier tendering against your contract rates, dynamic re-routing as new orders land, ETAs predicted from your own delivery history, and fleet maintenance scheduled against mileage and MOT dates.
The core data the system manages is consistent across builds: orders, routes, individual stops, drivers, vehicles, customers, delivery history and failed deliveries. Where it gets specific to you is the business logic on top: commission and driver-pay rules, pricing, approval steps and the exceptions your operation hits.
How a build runs
Discovery and planning starts with First Gear, a working prototype in 5 days. I run workshops to document how the day works now, where it hurts, and what the system has to do, and audit the address and customer data you’ll migrate. This is also where I’ll tell you if off-the-shelf would serve you better.
Development takes about a month for the first release, with regular check-ins so there are no surprises. I usually ship a focused version first, order intake, dispatch, the driver app with proof of delivery, live tracking and customer notifications, then add route optimisation, integrations and analytics in a second phase.
Testing and deployment covers QA and user testing, then a pilot with one depot or shift before the whole fleet moves over. Dirty addresses and duplicate customer records are the most common cause of a rocky launch, so they get cleaned during migration.
Training and support carries on after launch. Dispatchers need a half-day and a hand through the first weeks; drivers need a couple of hours with the app; managers need a session on the reports.
What it costs, and what you own
There’s an upfront cost. Most builds cost £2k–£10k, with the price fixed in the build plan; route optimisation, integrations, analytics and compliance features are added as later phases.
The case for it is the three-to-five-year picture. SaaS pricing tracks your volume, so growth keeps pushing the bill up, and the advertised rate rarely includes onboarding, integration work, overage fees or premium support. A custom system has a fixed build cost and predictable hosting and support afterwards, and the workflows fit, so nobody keeps a spreadsheet alongside it. You own the source code outright: no per-seat pricing, no surprise increases, no forced upgrades, and no risk of the platform being shut down or left to stagnate. You can evolve it for years without renegotiating a contract.
Who this works for
The requirements differ more by sector than you’d expect:
- Retail and eCommerce: same-day and next-day delivery, cost per delivery tracking, a customer tracking portal, and routing across in-house vans and external couriers
- Food and drink: temperature-controlled loads, tight delivery windows, kitchen-to-driver handoff, and temperature logs for freshness and safety claims
- Pharmacy and healthcare: moving medicines with ID-checked, signature-required proof of delivery, minimal patient data in the driver app, chain-of-custody, temperature monitoring and an audit trail that stands up to inspection
- Field services: HVAC, plumbing and utilities, where the delivery and the install are one job, with skill-based dispatch, time-window scheduling and before-and-after photos
- Courier, 3PL and logistics firms: managing internal fleets alongside subcontractors, multi-carrier handling, and white-label platforms a franchise can run under its own brand
- Construction: scheduling heavy materials to multiple sites with vehicle and access constraints
- Wholesale distribution: high-volume routes with load optimisation and weight limits
- Subscription and recurring delivery: meal kits and regular supplies, with delivery calendars, customer self-service rescheduling, and pause, skip and resume
- Florists and other perishables: moving stock against the clock with tight windows
- Waste collection: weighbridge data and recycling reporting tied into the round
- Hazardous goods carriers: ADR documentation and a handling record at each stage
Common trigger points are similar across all of them: outgrowing spreadsheets, a failed audit or a complaint with no proof of delivery to fall back on, opening a second or third depot, a move to same-day or two-hour windows that manual dispatch can’t hit, duplicate data entry between eCommerce and dispatch, or per-stop pricing that has quietly stopped making sense.
Common Questions About Custom Delivery Management Systems
How does a custom build compare on cost to delivery SaaS? ›
There's an upfront cost: most builds are £2k to £10k, fixed before work starts. SaaS platforms charge per driver, per vehicle, per user or per stop, so the bill grows with your volume and fleet, before overage fees, API charges and add-ons. A custom system has a fixed build cost and predictable hosting afterwards. Put your current bill and next year's expected volume next to the build price and the comparison over three to five years is usually clear.
Should we just use Onfleet, Shipday or similar instead? ›
Often, yes. If you run a single region at modest volume, with standard dispatch rules, a stable fleet and integrations already on the vendor's list, an off-the-shelf platform will cover you and cost less than a build. Custom makes sense when the standard tools fight your process: multi-tier driver commission or pricing, a hybrid internal-and-courier fleet, deep integration with a legacy ERP that has no usable API, a chain-of-custody record your regulator expects, or per-stop pricing that no longer adds up. I'll tell you which side of that line you're on.
What's the typical timeline? ›
A focused first version covering order intake, dispatch, a driver app with proof of delivery, live tracking and customer notifications usually goes live within a month. Route optimisation, eCommerce and accounting integrations, analytics and compliance features follow as later phases, each with its own fixed price and about a month of work. The build plan at the end of First Gear sets out the phases so route optimisation or extra integrations can land later rather than holding up go-live.
Can you integrate with our existing systems? ›
Yes. Common connections are eCommerce platforms (Shopify, WooCommerce, Magento), accounting and ERP (Xero, QuickBooks, NetSuite, SAP), carrier APIs (DPD, Royal Mail, DHL) for labels and tracking, vehicle telematics, payment tools, and SMS and email providers like Twilio and SendGrid. Where a legacy system has no API, I build the middleware.
What about data security and UK compliance? ›
Delivery systems hold customer addresses, phone numbers and driver location data, so UK GDPR applies. I build in role-based access, tamper-evident audit logging of who assigned and changed what, defined retention periods, and right-to-erasure handling. Hosting can sit in a UK region for data residency. For regulated work such as pharmacy or temperature-controlled food, I add chain-of-custody and temperature records and an ISO 27001-aligned setup.
How do you handle changes and support after launch? ›
You own the source code, so you're never locked in. Every build has a 30-day fix guarantee and the first month of hosting free; after that you can take a monthly plan or host it yourself. Because the system is yours, you can add modules as the operation grows without renegotiating a contract or waiting on a vendor's roadmap.
Do you provide training for our team? ›
Yes. Dispatchers usually need a half-day plus support through the first few weeks; drivers need a couple of hours hands-on with the mobile app; managers need a session on the reports and alerts. I document the system and stay reachable while everyone settles in.