Case 02of 08
Halden Software for people wearing gloves
Thirty-four engineers servicing industrial pumps, filling in paper job sheets that someone re-keyed every evening. Invoices ran eleven days behind the work. We built the tool that closed the gap — and learned in week five that it had to work with no signal at all.
Dispatch board — sync state is a first-class piece of informationFig. 01
The problem
Every job produced a triplicate paper sheet. The engineer filled it in, the customer signed it, one copy stayed in the van, and an administrator typed the other into two systems that evening — once for invoicing, once for parts.
The cost was not the typing. It was the eleven-day lag between finishing work and billing for it, and a parts inventory wrong often enough that engineers had started keeping private stashes in their vans. One engineer had £3,400 of seals behind his passenger seat, and he was right to.
- ~20 hours a week of re-keying across three depots
- Parts write-offs running at 9% of stock value
- Signed sheets lost or illegible on roughly one job in twenty
- No way to see what an engineer had done until the next day
- Median 11 days from signature to invoice; worst case 34
Before and after
The job sheetHours a week spent re-keying job sheets. The administrator who used to do it now runs the parts function, which is the job she actually wanted.
Designed for the van
This tool is used standing up, outdoors, in gloves, often in bright sun, on a phone that is already dirty. That constraint set the whole interface: 56px minimum targets, no dropdowns, no free text where a choice would do, and contrast well past AA.
We shadowed four engineers for a day each before drawing anything. The most useful thing we learned was that the job sheet is filled in twice — roughly while working, then properly before the customer signs. Every previous attempt at this software had modelled one pass, which is why none of them were used.
- 56px targets, tested with work gloves on, not approximated
- Draft and confirm as two distinct states, because that is the real behaviour
- Photo capture attached to the line item, not to the job
- Parts added by scanning, with a four-tap manual fallback
- Signature captured on the engineer’s own phone, in portrait
A job, end to end
From arrival to invoiceMarch is the partial month: the first depot moved across on the 14th. April onwards is all three depots. Median rather than mean, because two disputed jobs in May would otherwise have hidden the change.
The rebuild
Version one assumed connectivity. It was wrong. Pump rooms are underground, plant rooms are Faraday cages, and a third of jobs had no usable signal at any point.
In week five we stopped feature work and rebuilt the data layer offline-first: every action written locally, an explicit queue the engineer can see, and conflict resolution that never silently discards what someone typed. Sync stopped being plumbing and became a piece of information on the screen — which is why engineers trust it.
- Full offline capture, including photos, with a visible queue
- Deterministic sync, idempotent on the server, no lost writes
- Conflicts surfaced to a human rather than resolved by timestamp
- Invoice drafted automatically from the signed sheet, reviewed by a person
- Tested by pulling the SIM out mid-job, repeatedly, on real devices
Sync, made visible
States and constraintsResults
Each with its methodThey stopped building and came out in the van with us. The version after that was the one the lads actually used, and nobody had to be told to use it.
LogWeek by week
The build log
Twelve weeks, including the three we spent rebuilding something we had already shipped.
Paid discovery at the Rotherham depot. Two days of ride-alongs, every paper field catalogued, the accounting integration documented. Scope and fixed price agreed.
Job sheet designed and built. Draft-and-confirm modelled from the ride-alongs. First version on eight engineers’ phones by the end of week three.
Reality. Engineers reported jobs ‘not saving’. They were saving, then being lost when the app reloaded with no signal. We went back out in the vans.
Offline rebuild. Local-first writes, visible queue, idempotent server, human conflict resolution. Feature work stopped entirely. We carried the cost.
Parts and scanning. Van-level stock, reconciliation against the depot, and the four-tap manual fallback for the barcodes that never scan.
Dispatch board and invoicing hook. Draft invoices into their accounting system, always reviewed by a person before sending.
Rollout, one depot a week. Two days on site per depot, standing in the yard at 7am when the vans went out.
Handover: source, runbook, on-call playbook. Two weeks of shadowed support where their developer took the calls and we listened.
What shipped
Six deliverablesWhat we would do differently
We should have gone out in the vans in week one, not week five. The offline rebuild cost roughly three weeks that a single day of field observation would have saved, and we carried that cost rather than the client. It is now a fixed part of discovery: if the software is used somewhere we have not stood, we have not scoped it.
Who did it
CreditsProduct design, front end, offline data layer, rollout. One person, eleven weeks.
Back end and accounting integration. Same developer as Meridian, three days a week from week six.
Operations lead as decision-maker, four engineers who gave up their days for ride-alongs, one depot manager who ran the pilot.
Two build slots openNext start: March