Logistics & supply chain
Every shipment is an event stream
Tracking, driver and fleet apps, warehouse integration and customer notifications — built for patchy connectivity and events that arrive late, twice, or out of order.
Field apps are designed offline-first by default, not as an upgrade.
What makes logistics software different
The core data structure is an append-only stream of events from the physical world, and those events are unreliable in specific ways. A driver's phone loses signal in a basement and syncs four scans an hour later. A hub scanner fires twice. A delivery is marked complete before the pickup event arrives.
Systems that assume events arrive once, in order, and promptly will produce shipments in impossible states — and in this sector an impossible state means a customer being told something untrue about where their parcel is.
Add addresses that are descriptions rather than coordinates, cash collected on delivery, and a driver workforce that changes frequently, and the design constraints look very different from a warehouse-management textbook.
What logistics clients bring us
Five recurring problems.
Drivers working with no signal
Apps that stop working underground, in rural areas or inside warehouses. Offline-first with a sync queue and conflict handling is the fix, and it has to be designed in from the start.
Customers calling to ask where it is
Proactive notifications at each meaningful event — over SMS or WhatsApp — remove most of that call volume and reduce failed deliveries at the same time.
Carrier integrations that all differ
Every carrier has its own API, its own status vocabulary and its own idea of what 'delivered' means. Normalising them behind one internal model is the recurring engineering task.
Proof of delivery disputes
Signature, photo, timestamp and location captured on the device and synced reliably — plus the audit trail that settles the argument later.
Nobody agrees on the numbers
On-time percentage differs depending on who calculates it and from which system. Usually a definition problem before it's a reporting one.
Where we help most
The services that carry most of our logistics work.
Mobile App Development
Driver and field apps with offline queues, scanning, photo capture and battery-aware location tracking.
Enterprise Integration
Normalising carrier APIs, WMS feeds and customer systems into one event model that everything else reads from.
Communication Platform
Dispatch and delivery notifications over SMS and WhatsApp, including the pre-delivery message that prevents a failed attempt.
Custom Software Development
Control towers, dispatch consoles and the operational tooling that replaces the whiteboard and the shared spreadsheet.
Data & Analytics
On-time performance, cost per delivery and failure-reason analysis — with definitions everyone has actually agreed.
Designing for the field, not the office
Four constraints we treat as requirements rather than edge cases.
Assume no connection
Every action a driver takes must complete locally and sync later. If the app needs a network round-trip to record a delivery, it will fail at exactly the wrong moment.
Assume events arrive out of order
Shipment state is derived from the event stream, with each event carrying its own occurred-at timestamp. Late-arriving events are reconciled rather than rejected.
Assume duplicates
A scanner fires twice, a driver taps twice, a retry succeeds after a timeout. Every event carries an idempotency key so replaying it changes nothing.
Assume the battery matters
Continuous GPS tracking will drain a phone before the shift ends and drivers will disable it. Adaptive sampling gets useful location data without killing the device.
Most logistics rescue projects we take on failed on one of these four, not on anything more sophisticated.
FAQ
Logistics & supply chain
Can you integrate with our existing carriers?
Usually. We've worked with modern REST APIs, older SOAP interfaces and carriers whose integration is a scheduled file exchange. The approach is to normalise all of them behind one internal event model, so adding or replacing a carrier later doesn't ripple through your whole system.
How do you handle drivers with unreliable phones?
Design for the worst device and the worst connection you actually see in the fleet. That means offline-first storage, a visible sync queue so drivers know what's pending, small app size for cheap data plans, and adaptive location sampling that doesn't drain the battery before the shift ends.
Can you handle cash on delivery reconciliation?
Yes, and it's a distinct piece of engineering. Cash collected by drivers has to be tracked per shipment, reconciled against deposits, and audited — it's effectively a financial subsystem inside your logistics platform and we scope it as one rather than as a checkbox on the delivery screen.
Do you build the customer tracking page too?
Frequently, yes — a branded tracking page plus proactive notifications is usually the highest-return customer-facing work in this sector. It reduces inbound calls and, when the pre-delivery message prompts someone to be home, it measurably reduces failed attempts.
Can you work with our existing WMS?
Yes. Replacing a warehouse management system is rarely the right first move — integrating with it and building the missing layer around it usually delivers more, faster. We'll tell you if the WMS genuinely is the constraint rather than assuming it isn't.
Where does the tracking break down?
The scan that doesn't sync, the carrier whose status never matches, or the customer calls you can't reduce. Any of them is a good place to start.
← All industries