Four OEM portals and a spreadsheet, replaced by one fleet record.

Four OEM portals and a spreadsheet, replaced by a single normalised fleet record and an offline-first app in every cab.

Client

A civil earthmoving contractor

Industry

Earthmoving & heavy plant

Duration

20 weeks + run

Team

2 senior · 2 mid · 1 data · 1 SRE

Stack

Flutter · Go · Postgres · Timescale · GCP

Engagement

Dedicated team

The situation

Four OEM telematics portals, three unit systems and one supervisor logging into all of them every morning to build a spreadsheet by hand. Nothing reconciled against what the business had actually invoiced.

Prestart inspections and defect reports left the gate on paper. When an incident was investigated, the paperwork was in a glovebox.

Constraints we worked inside

Connectivity

No usable signal at three of eleven sites for most of a shift. Anything an operator touches has to work fully offline.

Mixed fleet

Four OEMs exposing hours, fuel and position differently, and disagreeing on what an engine hour is.

Hardware

Ruggedised tablets on 4G, gloves-on operation, and screens read in direct sun.

Safety

Prestart and defect records had to satisfy the plant record-keeping rules in the client’s jurisdiction from day one.

Architecture

What we shipped, anonymised.

four OEM adapters behind one normalised machine record

Clients

Operator app — offline-first new
Supervisor web board new

Edge

Sync API — idempotent batch upload, conflict resolution by device clock skew tolerance new

Ingest

ISO 15143-3 poller
OEM adapters ×4
J1939 gateway feed

Services

Normalisation new
Utilisation & idle new
Service scheduling new
Defect workflow new

Data

Postgres — assets, defects, work orders
Timescale — telemetry series
Object store — inspection photos

Decisions & tradeoffs

The calls we made, and what each one cost.

Decision 01

One canonical machine record, adapters at the edge.

Every OEM quirk is absorbed in its own adapter and never leaks past it. Adding a fifth OEM is now a two-week job instead of a refactor.

TradeoffAn adapter layer to maintain, and a normalisation spec to keep honest.

Decision 02

Offline-first, with a conflict policy written before any code.

A shift produces work the server has never seen. We defined precedence rules with the client’s safety team first, then built to them.

TradeoffSlower start; the first eight weeks produced very little anyone could see.

Decision 03

Idle detection from telemetry, not from operator input.

Asking operators to log idle time would have produced compliant, useless data. We inferred it from engine and hydraulic signals instead.

TradeoffPer-model calibration for each machine class in the first quarter.

What we’d do differently

We built the supervisor web board before the operator app. Supervisors were the buyer, but operators were the ones who had to adopt it — and adoption was what the whole business case rested on. We would build for the cab first now.

Next case study

A checkout that failed slowly, made fast and recoverable.

Read it →

Got a system like this one?

Ask us for a code sample or an architecture walkthrough from a comparable project. Anonymised, no NDA required, no sales call attached.

Scope your project

Tell us what’s stuck.

A senior engineer reads every one of these. If we’re not the right fit we’ll say so, and point you at someone who is.

Start the conversation

No spam, no drip sequence. A senior engineer replies within one business day.