This piece was written for enterprise technology leaders and originally published on the Wednesday Solutions mobile development blog. Wednesday is a mobile development staffing agency that helps US mid-market enterprises ship reliable iOS, Android, and cross-platform apps — with AI-augmented workflows built in.
Hub-and-spoke logistics networks have distinct mobile requirements at every node. An app built for the driver misses what the hub manager needs. An app built for the hub misses what the driver needs. Here is the full picture.
A hub-and-spoke logistics network is three different operations running simultaneously: a sorting operation at the hub, a line-haul operation between the hub and spokes, and a last-mile delivery operation at each spoke. Each operation has a different pace, a different set of tasks, and a different set of things that go wrong. A mobile app built for one of them and stretched to cover the others produces tools that no one trusts because the tools do not match the work.
The cost of a poor fit is visible in operational data: hub sort accuracy rates that should be above 99.5 percent running at 97 percent, driver departure times that should be at the scheduled window running 20 to 40 minutes late, and last-mile delivery rates that vary by spoke in ways that reflect tool quality rather than demand patterns.
Key findings
The single most operationally consequential feature difference between a well-built and a poorly-built hub mobile app is scan-to-sort confirmation speed. Hub sorters processing 400 parcels per hour need a scan confirmation in under 300 milliseconds with a clear audible and visual sort destination signal. A scan confirmation that takes 800 milliseconds and requires a confirmation tap produces a missort rate that compounds through the spoke network - one missort at the hub becomes a two-day delay at the spoke.
Driver apps in hub-and-spoke networks have a different primary requirement from last-mile driver apps: route loading speed at departure. A driver who receives a 120-stop route at the hub needs the full route - all addresses, all parcel identifiers, all delivery instructions - loaded to the device before they leave the hub, not fetched stop-by-stop as they drive. A route that loads incrementally in the field produces stops where the driver has no delivery data, which creates missed deliveries that look like driver errors but are app failures.
Operations center visibility across a multi-hub network requires a different data architecture than single-hub visibility. The operations center needs aggregated metrics - parcels scanned per hub per hour, sort accuracy rate, driver departure status, spoke delivery completion rate - updated on a sub-minute cycle. The driver app and hub app generate this data as a byproduct of their primary functions; the architecture decision is whether to build real-time aggregation into the backend from the start or add it later. Adding it later is significantly more expensive.
The three nodes and their different needs
A hub-and-spoke network has three distinct node types with distinct operational requirements.
The hub is a high-volume sorting environment. The primary tool is a handheld scanner or tablet used by sorters who process hundreds of parcels per hour. The interaction pattern is repetitive and fast: scan, confirm sort destination, place, next. The tool needs to be accurate, audible, and fast. It does not need to display maps, manage routes, or handle complex input. Complexity in a hub scanning app is a liability, not a feature.
The spoke is a dispatch and staging environment. Hub managers at spokes receive incoming loads, scan parcels onto outbound routes, and dispatch drivers. The interaction pattern is multi-step and involves coordination: confirm inbound load, match parcels to routes, confirm driver departure. The tool needs to handle multi-parcel workflows and surface exceptions clearly.
The last-mile is a navigation and delivery environment. Drivers follow routes, execute deliveries, and capture proof of delivery. The interaction pattern is mobile, one-handed, and time-pressured. The tool needs to present the next action clearly without requiring the driver to navigate a complex interface.
These three nodes have different devices, different interaction patterns, and different failure modes. Designing one app to cover all three produces an interface that no node finds natural.
What the driver app needs
The driver app has five core requirements. First, full route pre-loading: the complete route - all stops, all parcel details, all delivery instructions - must be on the device before the driver leaves the spoke. No stop should require a network fetch during the route.
Second, clear next-action display: the driver's screen should show one thing at a time - the current stop address, the parcel count for that stop, and the delivery instructions. Not a map with 40 pins and a list of all remaining stops. One stop, clearly presented, with navigation to the next stop triggered after the current stop is confirmed.
Third, offline-first proof of delivery: photo, GPS, and timestamp captured and stored locally at the moment of delivery, synced to the backend when connectivity is available. Not dependent on a live connection at the point of drop-off.
Fourth, exception handling without friction: a delivery that cannot be completed - no access, wrong address, customer not present for signature-required parcels - needs a one-tap exception flow that records the attempt, captures the reason, and moves the driver to the next stop. Exception flows that require multiple screens slow the route and produce abandoned attempts.
Fifth, end-of-route submission that requires no manual action: when the driver completes the last stop, the route summary should compile and submit automatically. The driver should not be required to navigate to a submission screen, fill in fields, or confirm a form. The day ends when the deliveries end.
What the hub manager needs
The hub manager app has different priorities. Where the driver app presents one thing at a time, the hub manager app needs multi-parcel visibility: inbound load confirmation, sort-to-route assignment, and departure management for multiple drivers simultaneously.
Inbound load confirmation is the first function: scanning parcels off an inbound vehicle against a manifest, with immediate flagging for parcels that are unexpected or damaged. The scan flow needs to be fast enough to keep pace with unloading - one scan per two to three seconds is typical for a hub unloading operation.
Sort-to-route assignment is the second function: after inbound confirmation, the app assigns each parcel to an outbound route and displays the bin or staging area for that route. The assignment can be automatic based on parcel ID and route manifest, or manual for exceptions. The display needs to be visible in a warehouse environment - high contrast, large text, audible confirmation for missorts.
Departure management is the third function: the hub manager confirms that all parcels for a route are staged before dispatching the driver. The app should surface a pre-departure checklist automatically - parcel count against route manifest, driver sign-on confirmation, vehicle check - that prevents a driver leaving with an incomplete load.
What the operations center needs
The operations center does not touch parcels. It monitors the network. The mobile-facing requirement from the operations center is a real-time dashboard that aggregates key metrics from all hubs and all spokes without requiring manual reporting from hub managers.
The metrics that matter: parcels scanned per hub per hour against throughput target, sort accuracy rate per hub, driver departure status against scheduled window, parcels in exception queue per hub, and spoke delivery completion rate by hour.
These metrics are generated by the hub apps and driver apps as a byproduct of normal operation. The architecture decision is whether the backend is built to aggregate and surface them in real time from the start, or whether real-time visibility is added later as a separate project. Retrofitting real-time aggregation to a backend that was not designed for it typically costs two to three times more than building it in from the beginning.
Read more case studies at mobile.wednesday.is/work
Where unified vs. separate apps makes sense
A single app with role-based views is the right answer for smaller operations where the same person may fill multiple roles at different points in the shift: a hub manager who also drives a spoke route, or a driver who also handles hub scanning during peak periods. Role switching in a single app is lower-friction than switching between apps when roles overlap.
Separate apps are the right answer for operations where roles are fixed and volumes are high. A hub processing 8,000 parcels per shift has dedicated scanners who never drive. A spoke dispatch manager who never touches a driver route. Separate apps optimized for each role produce higher accuracy and faster throughput than a combined app that includes unused features for every user.
The architecture that supports both models is the same: a shared backend with role-specific frontends. Starting with a shared backend and building separate role-optimized apps on top of it costs more upfront than building a single app, and significantly less than rebuilding a single app into separate apps after the operation grows to the point where the compromise is no longer acceptable.
Want to go deeper? The full version — with related tools, case studies, and decision frameworks — lives at mobile.wednesday.is/writing/hub-and-spoke-logistics-mobile-app-requirements-2026.
