Work01 / 06Logistics2025Sample
Control Tower
A real-time dispatch platform that lets one team see, decide and act on every vehicle in the network.
SampleIllustrative case study with placeholder figures — replace it with your own project.
- Client
- Regional logistics operator
- Industry
- Logistics
- Year
- 2025
- Platforms
- Web
- Android driver app
- Engagement
- 9 months(placeholder) · discovery to launch
- 6(placeholder) · people on the team
The problem
Dispatch ran on four tools and a lot of phone calls.
Every late delivery meant someone stitching together a telematics portal, a shared spreadsheet of exceptions, the ERP and the phone — under time pressure, with customers waiting.
Information arrived in the wrong order, decisions lived in people's heads and nothing was recorded for the next shift. The operator wanted dispatchers to spend their time deciding, not searching.
- vehicles across three depots
- 340(placeholder)
- vehicles across three depots
- stops planned every day
- 1,800(placeholder)
- stops planned every day
- tools open during every incident
- 4(placeholder)
- tools open during every incident
Our approach
One map, one queue, one decision at a time.
Strategy
Two weeks in the dispatch room
We shadowed every shift, logged each incident end to end and ranked them by cost. Late pickups and temperature alerts accounted for most of the work, so they shaped the first release.
UX & UI
Designed for a wall screen and a fast hand
A dark interface for 12-hour shifts, a map that always shows the context of the selected problem, and suggested actions that explain their impact before anyone commits.
Engineering
Event-driven from the first commit
Vehicle positions stream in every few seconds. An event pipeline orders them, recalculates ETAs and pushes changes to every open screen in under a second.
The product
What dispatchers use every day
Live network map
Every vehicle, depot and pickup on one map, with traffic and predicted ETAs updating continuously.
Exceptions with context
Selecting a problem draws the affected route, the cause and the knock-on effect on the next stops.
Suggested actions
The system proposes the best reassignment with its cost and time impact. Nothing changes without a click.
Act and notify in one step
Applying a change updates the driver app, the ERP and the customer, and closes the exception with an audit record.
Architecture
Built around an event stream
Telematics, orders and driver updates all become events. Services subscribe to what they need, so ETAs, the map and notifications stay consistent without polling.
Out-of-order data, handled
Positions are processed in event time with a short watermark, so a late GPS ping never rewinds a vehicle.
Sub-second screens
Changes reach every open dispatcher screen over a WebSocket within a second of the event.
The ERP stays in charge
An integration service batches updates so the ERP remains the system of record without real-time load.
Challenges solved
Where it got hard
Dispatchers didn't trust automated suggestions.
Solution: Every suggestion shows its reasoning and impact, and nothing is applied without a person confirming it.
Telematics data arrived late and out of order.
Solution: Event-time processing reconciles positions before ETAs are recalculated.
The ERP couldn't take real-time writes.
Solution: A batching integration layer protects the ERP and keeps it authoritative for orders and billing.
Outcome
Fewer tools, faster decisions, a record of every one.
Dispatchers now work from one screen. Exceptions are resolved faster, customers hear about changes before they call, and each shift starts with a complete history of the last.
- time to resolve an exception
- −38%(placeholder)
- time to resolve an exception
- tools open during an incident
- 4 → 1(placeholder)
- tools open during an incident
- platform availability
- 99.95%(placeholder)
- platform availability
Technology
- Applications
- TypeScript
- Next.js
- NestJS
- Python
- Data
- Kafka
- PostgreSQL
- PostGIS
- Redis
- Infrastructure
- AWS
- Kubernetes
