Software for logistics and supply chain
The driver is in a basement, on a two-year-old phone, at four percent battery, and needs to record a delivery. Every architectural decision in a logistics system should be made with that person in mind, because they are the one generating your data.
Every sector page here leads with the modelling problem that sector actually has — the exception that breaks the schema, the number two systems disagree about. If it could be rewritten for another industry by swapping six nouns, it would not be on this site.
Build for the worst connection, not the demo
A driver app that assumes connectivity will fail in exactly the places deliveries happen: basements, industrial estates, lift lobbies, rural stretches. If capture depends on a live connection, the driver records it later from memory, and the timestamp on your proof of delivery becomes approximately fictional.
So the app is local-first. The delivery is recorded on the device, the driver can see plainly whether it has synced, and the sync handles conflicts by an explicit rule. The signature, the photograph and the GPS position are captured at the moment of the event and queued — not requested at the point of upload.
Battery is a feature too. Continuous high-accuracy location tracking will flatten a phone by early afternoon, and a driver whose phone is dead has stopped generating data entirely. Adaptive sampling — frequent while moving, sparse while stopped — is the difference between a system that runs all day and one that does not.
What "delivered" means
It sounds obvious and it is the most contested field in the system. Delivered to the person named? To the security desk? Left at the door with a photograph? Partially delivered because two cartons were damaged and refused? Each of these is a different state with different consequences for billing, for the customer’s stock record and for the claim if something is disputed later.
A system with one delivered flag will have that flag set in all four situations, and the disputes it produces will be settled by phone calls rather than by records. Modelling the states properly is unglamorous and pays for itself the first time a consignment is contested.
Billing that reconciles
Freight billing goes wrong in the gap between what was planned and what happened: a detention charge nobody logged, a re-attempt that was not authorised, a weight discrepancy at the destination, a fuel surcharge applied against the wrong rate card period.
Capturing these as events at the moment they occur — rather than reconstructing them at month end from a driver’s recollection — is what makes freight invoices defensible. It is also what stops the argument, which is worth more than the individual charges.
The six things that decide a logistics & supply chain project
These are where the schedule goes, and where a generic implementation quietly fails.
Offline-first driver apps
Capture that works in a basement at four percent battery, with sync state the driver can actually see.
Dispatch and routing
Assignment against real constraints — vehicle capacity, driver hours, time windows — and re-planning when reality intervenes.
Proof of delivery
Signature, photograph, GPS and timestamp captured at the event, with delivery states modelled rather than flattened to one flag.
Fleet and telematics
Adaptive location sampling that survives a full shift, integrated with maintenance scheduled on engine hours.
Freight billing
Detention, re-attempts, weight discrepancies and surcharges captured as events when they happen, not reconstructed at month end.
Customer visibility
Tracking pages and notifications that reduce the "where is it" calls rather than generating more of them.
Systems for logistics & supply chain
Not a product list — these are the shapes of system this sector keeps needing, built to fit rather than configured to approximate.
- Dispatch and route planning with constraint-aware assignment
- Driver applications built offline-first, for cheap Android hardware
- Proof of delivery with modelled states and defensible evidence
- Fleet tracking with adaptive sampling and maintenance scheduling
- Warehouse management — receiving, put-away, picking, dispatch
- Freight rating, billing and reconciliation against rate cards
- Customer tracking portals and proactive exception notifications
Logistics & Supply Chain, answered
The questions that come up on a first call in this sector specifically.
How do you handle areas with no mobile signal?
The driver app stores everything locally and syncs opportunistically, which is a design decision made at the start rather than a feature added later. The driver sees clearly which records are pending, so nobody is guessing whether a delivery registered. Conflicts — the same consignment updated from two places — resolve by an explicit rule agreed with you, because "last write wins" is a business decision disguised as a technical default. Retro-fitting this into an app that assumed connectivity is effectively a rewrite of its data layer.
Can you integrate with courier and 3PL APIs?
Yes, and the useful pattern is an internal abstraction over them rather than direct calls scattered through the code. Each carrier has its own idea of a status code, a service level and a tracking event; normalising those into your own vocabulary once means adding the next carrier is a mapping exercise rather than a change everywhere. It also means your reporting stays coherent when the carrier mix changes, which it will.
Will tracking drain the drivers’ phone batteries?
It will if it is implemented naively, and a dead phone generates no data at all. We use adaptive sampling — frequent updates while the vehicle is moving, sparse while stopped, and geofence triggers rather than continuous polling near known locations. We also test on the hardware drivers actually carry rather than on a current flagship, because that is where the difference shows up. Battery behaviour is treated as a requirement with a target, not as something discovered after rollout.
How long does a logistics platform take to build?
A focused first release — dispatch, a driver app and proof of delivery — is usually four to six months from discovery. Route optimisation, telematics integration and freight billing each add meaningfully, and we would generally sequence them after the core is live and being used. The part that most often surprises people is the delivery state model: agreeing what the states actually are, and what each one means for billing and for a disputed consignment, takes longer than building the screens that record them.
What this sector usually needs from us
- BuildMobile App DevelopmentReact Native when one codebase is genuinely enough. Native when it isn’t — and we will tell you which before you commit a budget.Read more
- BuildCustom Software DevelopmentCustom platforms, marketplaces and SaaS. We write the parts that are specific to your business and buy the parts that aren’t.Read more
- GrowAI & AutomationLanguage models pointed at the two or three tasks where they actually beat a rule — and kept away from the ones where they don’t.Read more
- RunCloud & DevOpsDeploys that are boring on purpose. Infrastructure as code, real environments, and a bill you can read line by line.Read more
Working in logistics & supply chain?
Tell us what your team works around every week. That is usually where the real project is, and it is a better opening than a requirements document.