Have you built a last mile delivery platform before?
Not a complete last mile and fleet platform, and we would rather say so than imply otherwise. Our published logistics work is a web based logistics management system with third party integrations and real time shipment tracking for an automotive parts supplier, and a supply chain management system covering inventory, demand forecasting and logistics for a supermarket chain. Both clients are named with verifiable reviews. We have also delivered a number of mobile applications, which is the transferable part here. Doorstep driver workflow and route sequencing would be new build for us.
Should we build this or use an existing delivery product?
If your delivery is standard parcel work, existing products and carrier services will beat a custom build on cost and time, and we will tell you that. Building becomes reasonable when your delivery is part of your customer experience and you want to control it, when your constraints are unusual such as chilled goods, installation, regulated items or two person handling, or when you need it embedded in systems you already run. We are willing to be paid for an assessment that concludes you should buy.
How accurate will the arrival estimates be?
Accurate enough to be useful, and we will not promise a minute. Estimates degrade the further down a route you look, because traffic, service duration and access difficulty accumulate. We therefore present a window that reflects that uncertainty, recompute as the round progresses, and show when it was last updated. If you want a tighter customer promise, the honest route is narrowing the operational commitment, not displaying a more confident number than the data supports.
Will the driver app work without signal?
Yes, and it is designed offline first rather than offline tolerant. The manifest is held on the device, completions and proof of delivery are queued locally, and submission is idempotent so a retry after signal returns cannot create a duplicate. The driver can see what is still queued. We treat basements, lifts, rural lanes and dead spots as normal operating conditions, because on any real fleet they are.
What about battery life on the driver phones?
It is a design constraint we test rather than a footnote. Continuous high frequency location tracking alongside navigation will drain a phone before the round ends, so we use adaptive sampling, restrained background activity, and efficient sync. We then run a full shift battery test on the actual devices your drivers carry, which are usually not the newest phones. If the result cannot support your round length we will tell you, and the answer may be in vehicle charging rather than more software.
Can we track our drivers continuously?
Technically yes, and we would ask you to decide deliberately how much you should. Continuous location is personal data about an employee, with obligations that vary by jurisdiction and often require notice, a stated purpose and a retention limit. We will build to the policy your legal advisers set, and we will design retention and access control to match it, including who may view an individual driver history. We are software engineers, not your legal advisers, so we will not tell you that a given approach is compliant.
How does it handle a failed delivery?
As a normal outcome with a structured reason rather than as an error. The driver records why at the doorstep, nobody home, refused, access blocked, damaged, wrong address, with any required evidence, and the system applies your rules: safe place, neighbour, retry the same day, reschedule, or return to depot. The customer is notified with the actual reason. The reason data is the valuable part, because a failure rate is only actionable when you can see which cause dominates.
Do you use Google Maps or something else?
Whichever fits your volume, coverage and licensing position, and we make the cost visible before committing. Google, Mapbox, HERE and open data based routing all have different pricing, terms and regional accuracy, and geocoding and routing calls are metered, so volume changes the economics materially. We design the routing integration behind an internal interface so the provider can be changed later without rebuilding the platform, since provider pricing does change.
Is this the same as your online food ordering page?
No. That page covers the consumer ordering journey for hospitality: menu, basket, checkout and order status. This page covers the operational side of getting goods to a door: dispatch, sequencing, the driver app, proof of delivery and exceptions. A food business may want both, and they meet where an order becomes a delivery task. If your question is how customers place orders, the online food ordering platform page is the right one.
Can it integrate with our existing vehicle trackers?
Usually yes. Many telematics units and platforms expose a feed or API, and reusing hardware you have already paid for is normally the sensible route. What varies is reporting frequency, event quality and whether the provider will give you raw position data or only their own reports. We check that specifically during discovery, because a tracker that reports every fifteen minutes cannot support live customer tracking regardless of what the platform above it does.
Who owns the code and the data?
You do. Source code, infrastructure configuration, documentation and operational data are yours, in your repositories and cloud accounts where you prefer that, and we hand over so another team can maintain it. This matters particularly for delivery evidence and driver location data, which carry retention and privacy obligations, so your control over that data must never depend on a continuing relationship with us.
