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 a UK business to bend its process around the tool. We work the other way round. At ByteGears we build delivery management systems around how your operation already runs.
There’s no monthly per-user or per-stop fee, because you own what we build. We’re a small London-based consultancy, and the systems we build tend to start narrow, cover the jobs that hurt most, and grow as the business does. You get the source code and a local team to call when something needs changing.
Where off-the-shelf delivery software gets in the way
For a single region, standard dispatch rules and under roughly 100 deliveries a day, a platform like Onfleet, Shipday or OptimoRoute is often the right call, and we’ll say so. The trouble starts when the operation has edges the tool wasn’t built for.
The recurring complaints we hear:
- Pricing scales the wrong way. Per-driver, per-user and per-stop models look cheap on the first invoice and climb with every delivery you add. At real volume, that’s thousands a month before overage fees, API charges and add-ons.
- Business rules don’t fit. Multi-tier driver commission, regional pricing, tips, performance bonuses and non-standard approval steps usually can’t be configured without the vendor’s engineering time, if at all.
- Integrations are shallow. Orders arrive from Shopify ten minutes late, sync runs one way only, and getting completed deliveries back into your billing system means someone exporting a spreadsheet.
- 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 actually 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 actually needed.
What ByteGears builds instead
We start by watching how your deliveries actually happen, from order intake through to a signed proof of delivery, then build software that fits that, not a generic version of it. You pay once for the build, plus a support package if you want one, instead of a fee that never stops.
The system connects to the tools you already run, and we design the integrations properly: address geocoding where order systems hold no coordinates, schema mapping so mismatched order formats line up, and two-way sync so a completed delivery flows back to billing without anyone re-typing it. Where a legacy ERP has no usable API, we build the middleware.
We build with UK GDPR in mind 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. When you need a hand, you’re talking to the London team that built it.
What goes into the systems we build
We shape the modules around your operation rather than shipping a fixed product. A typical build draws from:
- Order management — intake by manual entry, CSV import or API, with a clean queue and delivery-window handling
- Dispatch — assigning drops to drivers and vehicles by location, capacity and skill, manually or automatically
- Route planning and optimisation — multi-stop sequencing that accounts for traffic, vehicle capacity, weight and size limits, and time windows
- Driver apps for Android and iOS — the day’s jobs, turn-by-turn navigation, and offline-tolerant working for patchy signal
- Proof of delivery — signatures, photos and notes captured against each stop, with timestamps that hold up to scrutiny
- 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 tracking link
- Failed-delivery handling — capturing the reason, evidence and reattempt, so exceptions aren’t lost
- 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
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 actually hits.
How a build runs
It’s four phases.
Discovery and planning takes two to four weeks. We run workshops to document how the day works now, where it hurts, and what the system has to do. This is also where we’ll tell you honestly if off-the-shelf would serve you better.
Development runs eight to sixteen weeks, built by UK developers on modern frameworks, with regular check-ins so there are no surprises. We usually ship a focused first 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 is another two to four weeks of QA and user testing. Where it makes sense, we run the new system in parallel with the old one for a fortnight or so to de-risk the cutover.
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.
Most projects land in the three-to-six-month range, depending on how much there is to build.
What it costs, and what you own
There’s an upfront cost, no getting around it. A focused first version typically sits in the tens of thousands; a fuller platform with route optimisation, integrations, analytics and compliance features costs more again. We give you a real number after discovery, based on your scale, not a guess.
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 the day runs leaner. 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
We’ve built or scoped delivery systems across a range of UK sectors, and the requirements differ more 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 secure, signature-required proof of delivery, 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 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
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, expansion to multiple sites or vehicles, 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 a real upfront cost, and we won't pretend otherwise. The difference shows up over three to five years. SaaS platforms charge per driver, per user, or per stop, so the bill grows with your volume; at high delivery counts that can mean thousands a month before overage fees, API charges and add-ons. A custom system has a fixed build cost and predictable hosting and support afterwards. For operations doing solid daily volume, the maths usually turns in your favour somewhere around the two-year mark.
Should we just use Onfleet, Shipday or similar instead?
Often, yes. If you run a single region, under roughly 100 deliveries a day, with standard dispatch rules and no awkward integrations, 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, strict UK data residency, or per-stop pricing that no longer adds up. We'll tell you honestly 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 takes eight to twelve weeks. A fuller platform with route optimisation, eCommerce and accounting integrations, analytics and compliance features runs longer, more in the four-to-six-month range. We give you a phased plan after discovery 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), payment tools, and SMS and email providers like Twilio and SendGrid. We also handle the parts that usually go wrong: address geocoding for systems that store no coordinates, mapping mismatched order schemas, and two-way sync so completed deliveries flow back to billing. Where a legacy system has no API, we 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. We 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, we add the relevant audit trails 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. Support is a package that suits you, from occasional changes through to a regular maintenance arrangement. 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. We document the system and stay reachable while everyone settles in.