Skip to content

A freight portal that brings visibility to every mile

A real-time shipment visibility platform connecting carriers, shippers, and dispatchers with live tracking, geofence alerts, and automated status updates.

Live map
128 live loads across 4 carriers · positions interpolated between pings
All carriersLoad, registration or POThu 17 Sep 2026 · 13:48
128 live · 19 in view· one socket, scoped to the viewp90 update < 10sOn the road, in windowOutside windowInside a delivery geofenceFeed quietAt the yard
Load 44,812In window
Northgate Freight · NG24 KTV · TR-3318Daventry DC Ashdown Foods · Basildon depotKieran Doyle · 26 pallets · AF-PO-771204
Arrival ETA14:07Window 13:55–14:2543 mph · ping 22s ago
Recomputed 13:34 on entering the 10-mile ring

Milestones

Geofence crossings, as events
  1. CollectedDaventry DC · bay 1408:12
  2. Left the yardExited Daventry geofence08:31
  3. Break takenToddington services · 45 min11:26
  4. ApproachingEntered 10-mile ring13:34
  5. ArrivedSite gate polygonETA 14:07
  6. UnloadingDock bays polygon—

Driver hours

From the ELD · Kieran Doyle
Since last break1h 37m of 4h 30mDriving today4h 32m of 9h

What the engagement involved

Industry
Freight & Trucking
Duration
18 weeks
Cooperation model
Fixed price, phased
Services
Portal engineeringTelemetry pipelineCustomer tracking
Integrations
StripeSendGridSegmentSentry
Technologies
Next.jsTypeScriptNode.jsPostgreSQLMQTTWebSocketsMapbox GL
Team
1 Project lead1 Product designer2 Frontend engineers1 Backend engineer1 QA engineer

Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.

The problem

The hard problem

Location data was trapped in carrier portals, leaving dispatchers answering status calls and shippers guessing delivery times.

Location existed (every truck had an ELD reporting it) but it existed in four places the customer couldn't reach and the dispatcher had to visit one at a time. ETAs were quoted from the schedule instead of from the truck, so they were confidently wrong the moment anything went wrong, which is the only time anyone asks.

We built a unified freight portal that ingests carrier ELD and GPS data, renders live shipment maps, and alerts customers when loads cross geofenced milestones.

Introduction

The system we were asked to build

Shippers called dispatch constantly asking "where is my load?" We built a portal with live telematics tracking and automated status updates.

A third-party logistics operator moving freight across four carriers, each with its own portal and its own login. Dispatchers spent their day answering where-is-my-load calls by logging into whichever portal applied and reading a number back. The engagement was commissioned when the operator lost a contract on service scores that were, on inspection, entirely about visibility and not delivery performance.

Systems Integration & Engineering

How the pieces fit

  1. 01

    Integrated carrier ELD feeds and GPS telematics into one pipeline

    Carriers were integrated one at a time with each feed validated against known journeys, because a tracking map that is wrong once stops being opened.

  2. 02

    Designed a real-time tracking map with dynamic ETA recalculation

    Crossing a geofence is an event, so the ETA recomputes at the milestone instead of on a timer, and delay is judged against that leg's own history.

  3. 03

    Built automated geofence entry/exit alerts for shippers

    Alerts fire on geofence entry and exit, never on a schedule, which is what makes a warehouse arrival notification sub-minute instead of sub-hour.

  4. 04

    Shipped branded customer tracking links for self-serve status

    Customers get a token scoped to one shipment, so tracking needs no account and exposes nothing beyond the load it was issued for.

Live GPS & Telemetry Tracking Map

Real-time interactive Mapbox portal showing precise vehicle locations, speed, and route history.

Carrier ELD units publish over MQTT at a rate that would flood a browser, so telemetry lands in a broker, is smoothed and decimated server-side, and reaches the map over one WebSocket per session carrying only the vehicles in view. Positions are interpolated between pings so trucks glide instead of jumping, and route history is drawn from the stored track, never reconstructed from the current heading.

What shipped
  • MQTT ingest smoothed and decimated before it reaches the browser
  • One socket per session, scoped to the vehicles in view
  • History drawn from the stored track, not reconstructed
Network board
All 128 live loads · telemetry smoothed and decimated before it reaches this screen
Route history: stored trackLoad, registration or POThu 17 Sep 2026 · 13:48
1 socket · 32 vehicles in viewIngest 10,000+/min→ decimated to the view

Carrier feeds

4 carriers, one pipeline
NGFNorthgate Freight41 live loads46 reporting
BRKBrackwell Transport36 live loads1 quiet
PLWPellow Haulage29 live loads2 quiet
SDMSedgemoor Logistics22 live loads25 reporting

Load 44,769

Pellow Haulage · PH22 LNX
Last known position13:31 · A12 southbound, past J19
Could be within11 mi along the route
DriverSam Okafor
The pin stops moving when the pings stop. Nothing is drawn past the last fix.
Dispatch log
Beth Marsh called Sam Okafor13:41Device unplugged at a cab swap. On the A12 near J17, running to time.
Pellow Haulage told13:44Unit on PH22 LNX silent since 13:31. Asked to reconnect at the next stop.
Filter by stateAll 128On the road, in window97Outside window9Inside a delivery geofence14Feed quiet3At the yard5
On screen

The network board: 128 live loads filtered by state along the bottom, one socket carrying only the vehicles in view, and a load whose feed went quiet drawn as a last known position and a cone, with the call dispatch made about it.

Load 44,797 35 min down
Brackwell Transport · Magna Park, Lutterworth → Harlow Fresh DC · window 13:45–14:30
Edit rulesLoad, registration or POThu 17 Sep 2026 · 13:48

BK73 WRD · Aled Pryce

M1 southbound · ping 6s ago
ETA was14:15ETA now14:50Delivery window13:45–14:30
Slipped 13:21· Dispatch 13:21· Shipper texted 13:33, 12 min after

Judged against this leg's own history

M1 J13 → M25 J21 · weekday, 12:00–14:00
Minutes this leg has taken on past runs. A delay fires when the truck is slower than this road usually is, not slower than a flat average. Past runs per 2-minute band Projected from the live pings

Basildon depot · three rings

Who hears about each, and how quickly
RingOnWho hearsHowWithin
Approaching10-mile ringEntryDock team · BasildonDock screen + appUnder 1 min
ArrivedSite gate polygonEntryDock team, dispatchDock screenUnder 1 min
UnloadingDock bays polygonEntryShipper linkLink updatesUnder 1 min
DepartedSite gate polygonExitShipper, consigneeEmailUnder 1 min

Event log

Load 44,797
12:22Exited geofence · Magna Park yardETA 14:15 set
13:21Leg M1 J13 → M25 J21 slower than its historyETA 14:15 → 14:50
13:21Dispatch alertedBeth Marsh
13:33Shipper texted the new timeAshdown Foods · 14:50

Geofenced ETA & Delay Predictor

On screen

A nine-mile queue on the M1 north of London puts a run thirty-five minutes down against that leg's own history, the shipper texted the new time twelve minutes after the slip, and the three rings around the depot with the rules for who hears about each.

Calculates arrival ETAs dynamically and alerts dispatchers of traffic or border delays.

Geofences are polygons around the yard, the border crossing and the delivery point, and crossing one is an event: the ETA recomputes at the moment a milestone changes, not on a timer. Delay prediction compares the current leg against the same leg's historical distribution, so an alert fires when the truck is slower than that road usually is. A flat average would flag every slow road every day.

What shipped
  • Milestone crossings as events, not polled positions
  • ETA recomputed at the moment a geofence is crossed
  • Delay judged against that leg's own history, not a flat average

Shipper & Consignee Portal

Branded self-service tracking links allowing customers to monitor active deliveries 24/7.

Customers get a tokenized link scoped to one shipment, so tracking needs no account and exposes nothing else. The previous portal handed out logins that could see the whole book. The page carries the shipper's branding from a theme record, updates over the same socket as the internal map, and expires on delivery plus a retention window instead of staying live forever.

What shipped
  • Per-shipment tokenized links: no account, no wider access
  • Shipper branding applied from a theme record
  • Links expire on delivery plus a retention window
AFAshdown FoodsYour delivery · load 44,812
Arriving at Basildon depot14:07On timeExpected between 13:55 and 14:25 Updates by itself · last position 22s ago
8 miles away
Progress
  1. Collected08:12
  2. On the road08:31
  3. Approaching13:34
  4. Arrived
  5. Delivered
This link shows load 44,812 only · closes 14 days after delivery
On screen

The same load as the shipper sees it on a link with nothing to sign in to: the shipper's own colors, one route, five steps, and an arrival time that keeps itself current until the link closes after delivery.

Process

Phase by phase

  1. Phase 1: Telematics & Carrier API Audit

    ELD Device & Carrier Data Integration

    Audited telematics streams, ELD device connectors, and carrier tracking updates across 500+ daily shipments.

    • Telematics Data Schema
    • Carrier API Map
    • Data Privacy Audit
  2. Phase 2: Live Shipment Map UI

    Dispatcher & Customer Tracking Portal

    Designed high-density dispatcher and customer tracking portals with real-time location pins and geofenced ETA alerts.

    • Mapbox UI Component Library
    • Dispatcher Portal Specs
    • Figma Design System
  3. Phase 3: High-Frequency Telemetry Engine

    MQTT Ingestion & Delay Predictor

    Engineered an MQTT broker pipeline ingesting thousands of GPS telemetry updates per minute, with automated delay prediction.

    • MQTT Ingestion Engine
    • Delay Prediction Engine
    • Geofence Trigger Service
  4. Phase 4: Customer Rollout & Analytics

    Shipper Portal Launch & Performance

    Launched the portal to shippers and carriers, reducing tracking status calls by 54% and improving ETA accuracy to 98%.

    • Production Release Sign-off
    • Customer Portal Onboarding
    • SLA Monitor
Carrier feeds
One carrier at a time · a feed reaches the map only once it matches known journeys
Add known journeyLoad, registration or POTue 14 Jul 2026 · 10:20
Carriers, in rollout order
NGFNorthgate FreightOn the map since 2 JunLive
Schema mappedUnits matchedKnown journeysOn the map
BRKBrackwell TransportOn the map since 23 JunLive
Schema mappedUnits matchedKnown journeysOn the map
PLWPellow HaulageReplaying known journeysValidating
Schema mappedUnits matchedKnown journeysOn the map
SDMSedgemoor LogisticsStarts after Pellow is on the mapQueued
Schema mappedUnits matchedKnown journeysOn the map

Pellow Haulage · replay against known journeys

Held off the map until every journey matches
Units matched to trailers33 of 33Known journeys replayed3 of 5Held back from the mapUntil 5 of 5 match
KJ-PLW-08 · Harlow → Chelmsford No pings 11:02–11:09 · unit reset en route Known journey Feed replay
JourneyRouteDrivenReplay
KJ-PLW-07Tilbury → Basildon depot6 JulTrack matches
KJ-PLW-08Harlow → Chelmsford7 JulGap · under review
KJ-PLW-09Daventry DC → Basildon depot8 JulTrack matches
KJ-PLW-10Lakeside → Southend9 JulNot replayed yet
KJ-PLW-11Brentwood → Thurrock10 JulNot replayed yet
On screen

Carriers brought on one at a time: the third carrier's feed replayed against known journeys, a seven-minute gap under review, and the feed held off the map until every journey matches.

What it carries now

−54%

Status calls

98%

ETA accuracy

< 10s

GPS update rate

Status calls is the dispatch line's own inbound count, comparing the quarter after the customer links went live with the quarter before. ETA accuracy is the share of arrivals inside the predicted window, measured at the delivery geofence. Update rate is the ninetieth percentile interval between position updates reaching the map, not the average.

Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.

What the architecture settled

03
  1. 01

    Self-serve customer shipment tracking reduced inbound status calls by 54%.

    The calls went away because the answer was self-serve and trustworthy. A portal customers check once and find stale is one they stop checking and start calling about.

  2. 02

    Automated geofence triggers provided sub-minute warehouse arrival notifications.

    Sub-minute arrival warning changed the warehouse's behavior more than the shipper's: docks could be staged before the truck was visible from the yard.

  3. 03

    MQTT telemetry pipeline processed 10,000+ GPS updates per minute with zero lag.

    Decimating server-side is what made the rate sustainable. Pushing every raw update to every browser had been the obvious design, and it wouldn't have survived the fleet.

Ways of working

How the work was run

  1. 01

    A cross-functional team of 5 worked on a fixed price, phased basis over 18 weeks, covering Portal engineering, Telemetry pipeline, Customer tracking. We ran a standing mid-week checkpoint and written decisions in place of status meetings. Nothing shipped without a live demo first.

    Carrier integration was phased one carrier at a time, with each feed validated against known journeys before it fed the map, because a tracking portal that's wrong once is a portal customers stop opening. Shippers got the branded links in the third phase, once ETA accuracy had been measured instead of assumed.

One load, one ETA

The arrival time comes from the truck, not the schedule.

Load 44,812 on its way to the Basildon depot, replayed three ways: a ping that crosses a geofence, a queue that makes the leg slower than it usually is, and a driver-hours check that puts a break before the depot. Each shows how the ETA is recomputed and who hears about it. Switch tabs, or use the arrow keys once one is focused.

Most pings only move the pin. This one puts the load inside the ten-mile ring around the Basildon depot, and crossing a ring is an event: the ETA is recomputed at that moment instead of on the next timer tick, and the ring's own rules decide who hears.

Ping from NG24 KTVmqtt · telematics/ngf/NG24KTV · 13:34:08
  1. Ping lands in the MQTT broker
  2. Smoothed and decimated server-side
  3. Inside the 10-mile ring: an entry event
  4. ETA recomputed at the crossing
  5. The ring's rules decide who hears
Approaching ring entered · 13:34:08
Load 44,812 · arrival ETA14:0714:10Inside the window · 13:55–14:25
13:4513:5514:2515:05

Recomputed from the truck at the ring, not from the schedule

Who is told

  • Dock team · BasildonDock screen and appUnder a minute
  • Shipper linkUpdates over the same socketAs it happens
  • DispatchNo alert: still inside the windowNot told

Why it matters: the arrival warning comes from the ring being crossed, so the docks can be staged before the truck is visible from the yard.

Illustrative replay: clock times, minutes and message delays are examples; the order of events is how the engine works.

Architecture

From a ping in a cab to a time on a customer’s phone

Pushing every raw update to every browser was the obvious design, and it wouldn't have survived the fleet. The rate is made sustainable in the middle of the pipe, before anything reaches a screen.

  1. 01 · Source
    Carrier ELD and GPS unitsFour carriers, integrated one at a time. Each feed is validated against known journeys before it feeds the map.
  2. 02 · Ingestion
    MQTT broker10,000+ GPS updates a minute land in the broker and are smoothed and decimated server-side, never pushed raw to a browser.
  3. 03 · Engine
    Geofence and delay engineA ring crossing is an event, so the ETA recomputes at the milestone. Delay is judged against that leg's own history.
  4. 04 · State
    Stored track in PostgreSQLRoute history is drawn from the recorded track, not reconstructed from the vehicle's current heading.
  5. 05 · Delivery
    WebSockets to map and linkOne socket per session, scoped to the vehicles in view. Shipper links update over the same socket, p90 under 10 seconds.

What a customer can rely on

Accurate when it answers, honest when it can’t, scoped to one load

No feed reaches the map unproven

Carriers were brought on one at a time, each feed checked against journeys whose route was already known, because a tracking map that's wrong once is one customers stop opening.

A quiet feed is shown as quiet

When a device stops reporting, the map stops pretending: a last known position and a cone of where the load could be, never a pin moving on a guess.

One link, one load

Customer links are tokens scoped to a single shipment: no account, nothing else in the book visible, and the link expires after delivery plus a retention window.

Is your dispatch line still answering “where’s my load?” Scope your build in 3 minutes.

Scope your build
Have a project?

Let's talk

Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.