Home / Work / Force
CUSTOM SOFTWARE · FIELD OPERATIONS

When the data
can be faked,
trust the database.

Force tracks shifts, machine hours, attachment usage and breakdowns for heavy equipment fleets — excavators, breakers, loaders — from operator phones to a central admin dashboard. It is built for the environment it actually runs in: patchy connectivity, shared handsets, and a genuine financial incentive to overstate hours. Every integrity guarantee is enforced server-side, where the handset cannot reach it.

Sector
Heavy equipment rental & plant hire
Surfaces
Operator mobile app · admin web dashboard
Geospatial
Site geofencing, verified server-side
Connectivity
Offline-first — full shift without signal
Hosting
Client-owned infrastructure
100%
Offline-capable field workflow
~1s
Live ops updates on the dashboard
3
Report formats — CSV / XLSX / PDF
/ 01
The Problem

Plant hire is billed on machine hours. Machine hours were being recorded on paper, by the operator, at the end of a shift, and keyed in days later by someone in an office who had no way to verify any of it. The gap between what was recorded and what actually happened was pure margin leakage — and nobody could size it, because there was no ground truth to compare against.

The obvious fix — "give operators an app" — fails immediately in this environment. Sites have no reliable data connection. Handsets are shared and cheap. And crucially, the person entering the data is the person whose pay it affects. An app that simply accepts typed input digitises the problem rather than solving it.

Off-the-shelf telematics wasn't an option either: it assumes OEM hardware on every machine and a per-asset subscription. The fleet was mixed, nobody was going to retrofit it, and the operational history needed to stay under the client's own control.

/ 02
The Approach

We treated anti-fraud as an architectural requirement, not a feature. The design principle: never trust a claim the client app makes about itself. Every guarantee is re-established somewhere the operator's handset cannot reach.

Location is checked against the site's geofence on the server, using proper geospatial queries rather than a distance calculation the app could be persuaded to lie about. An out-of-zone shift is rejected and recorded in an audit trail, not silently accepted. Uploaded photographs are validated by inspecting the file itself rather than trusting what the client says it is. Shift duration is measured against a clock the user cannot wind forward.

The strongest guarantee is the quietest one: the impossible states are made impossible in the data model, not merely checked for in application code. A machine cannot be on two shifts, and an operator cannot be running two machines — not because a validation rule says so, but because the schema will not represent it. Taking over a machine from another operator is an explicit, audited action.

Offline is the default assumption, not a degraded mode. Writes queue locally and drain when connectivity returns, on a schedule, and when the app resumes. An operator can work a full shift in a dead zone and the record arrives intact when they drive back into coverage.

/ 03
The Hard Parts
  1. Designing for an adversarial user who is also your customer's employee Every control had to be strict enough to matter and invisible enough not to insult honest operators. The interface never accuses anyone: it asks for a meter photo and the typed reading, and validates the pair. Most operators never notice a control exists.
  2. Making offline-first genuinely reliable, not best-effort An outbox is easy; an outbox that survives force-quits, OS battery killers, connectivity flapping and app upgrades is not. Drain is triggered three different ways because any single trigger will eventually fail on some handset in some Android skin.
  3. Evidence photography at fleet scale Every shift produces images that are part of the billing record, so they have to be retained, access-controlled and backed up — without a per-gigabyte bill that grows with the fleet, and without a leaked link exposing a customer's site.
  4. A live dashboard that doesn't hammer anything The admin view receives shift starts and ends, breakdowns and handovers as they happen — roughly a second end-to-end — using a push model rather than dozens of browsers polling on a timer.
/ 04
The Outcome

Machine hours now arrive with a GPS fix, a timestamped meter photograph, a typed reading validated against the previous one, and a monotonic elapsed time — captured at the machine, by the operator, at the moment it happened. Billing rests on evidence rather than recall.

Because breakdowns are reported from the same app with photos attached, maintenance gets a structured fault history per asset for the first time — the raw material for exactly the kind of predictive-maintenance modelling we've built elsewhere.

And the whole system runs on infrastructure the client controls, portable by design, with an English-only v1 already prepared for Arabic and Hindi. No per-asset subscription, and no vendor holding their operational history.

The operator app — built to be usable in gloves, in sunlight, offline
Force operator app home screen showing idle state and a synced badge listing cached equipment and sites
Offline cache state, always visible
Force app showing a shift in progress with equipment ID, GPS coordinates, start meter reading and elapsed timer
Shift in progress · GPS + monotonic timer
Force app attachment check screen asking whether a hydraulic breaker is mounted on a Komatsu PC500 excavator
Attachment capture drives billing
Three taps to start a shift. The complexity — geofence checks, mock-GPS detection,
outbox queueing, meter validation — is entirely invisible to the operator.
Stack Flutter Next.js Offline-first sync Geospatial queries Real-time push Anti-tamper design Role-based access Reporting & exports Internationalisation

A control an operator can bypass
is a control you don't have.

FIELD DATA YOU CAN BILL ON

If your operational truth lives on paper,
you are pricing on a guess.

Contact Us →