Built for the gap at the gate.Built for the gap at the gate.

The problem

A mill loads a truck. The gateman reads the weighbridge through a window and writes the figure in a book. The book is typed into a spreadsheet at the end of the shift. A short load is argued about the following week, by which time the truck has done four more runs and nobody can say which one it was.

Every part of that is normal, and every part of it is where the margin goes. Shrinkage becomes a number in a monthly meeting, attributed to nobody and acted on by nobody.

What we built

A verification layer. Weights are read over the bridge's own API rather than typed. Orders are captured at the customer's gate, inside a geofence, online or off. Deliveries are confirmed in-fence and signed for. Every checkpoint writes an append-only event with an actor, a time and a place. At the end of it there is a shrinkage figure with a driver, a vehicle and a route attached to it.

Why East Africa first

Because the constraints here are the honest ones: patchy signal on the last mile, mobile money as the default rail, and a statutory tax window that does not care whether your line is up. Software that works under those conditions works anywhere. Software written for a warehouse with fibre does not survive a Thika Road run.

So the field apps are offline-first with a local queue, every mutation is idempotent, geofence maths runs on-device rather than through a paid map call, and eTIMS submissions queue durably with retries so a rail outage delays a document instead of losing one.

Where we are

In pilot. We onboard a small number of design partners with a weighbridge, a loading bay and a field sales operation, and each pilot runs on one site until the loop closes there. If that sounds like your yard, tell us about it.

Contact

hello@loadline.africa — Nairobi, Kenya.