Logistics

Tracking and field apps for teams without a signal

Logistics software has to stay honest while the physical world keeps moving underneath it. We build tracking, dispatch, and field tooling for teams coordinating movement across sites, carriers, and partners who all describe the same event in different words.

The pressure

What makes logistics software hard

Before anything about us. These are the constraints that shape every logistics build, and the reason generic delivery comes unstuck here.

01

Stale data looks exactly like fresh data

A position fixed three hours ago renders the same as one from ten seconds ago, and a dispatcher with thirty seconds to decide will treat them the same way.

02

Yards, basements, and dead zones

Drivers and warehouse staff work where signal is not. An app that assumes connectivity is an app that loses the entry and gets it retyped from memory.

03

Every partner defines in transit differently

A shipment crosses carriers, warehouses, and customer systems, each with its own vocabulary and its own idea of what a status means.

What we build

Logistics capabilities

Four areas we take on in this sector. Each one is work we do rather than a category we list.

Tracking that admits what it does not know

The dangerous failure in logistics software is not missing data. It is a three-hour-old position rendered with exactly the same confidence as a live one, in front of somebody about to commit a vehicle to it.

  • Shipment and consignment tracking
  • Fleet and vehicle status views
  • Last-updated shown on every reading
  • Map-based movement views
  • Customer-facing tracking pages
  • Full event history per shipment
Problems and approach

Where these projects actually go wrong

The recurring failure patterns in this sector, what we do differently, and what that changes. You will not find a claimed figure here. Those belong to engagements we can name, and we do not name what we cannot evidence.

Problems we solve

Dispatch decisions get made against location data that is hours old, and nothing on the screen says so.

Solutions we deliver

Freshness surfaced wherever data appears: a last-updated time on every reading and an explicit stale state instead of a confident-looking number.

Impact you will see

An old reading looks old rather than being silently wrong.

Problems we solve

Drivers lose entries when signal drops in a loading bay, so status updates get retyped later from memory.

Solutions we deliver

Offline-first apps that record and queue locally and reconcile on reconnect, with conflicts raised for a person instead of overwritten.

Impact you will see

Field data survives the dead zone it was captured in.

Problems we solve

Every carrier reports status in its own vocabulary, so answering where a shipment is means opening three portals.

Solutions we deliver

An integration layer that normalises partner feeds into one internal status model and keeps the original payload for when a claim is disputed.

Impact you will see

One consistent answer about where something is, with the partner original still available when it is contested.

Problems we solve

The operations dashboard shows every shipment at once, so the four that need attention sit among the hundreds that do not.

Solutions we deliver

Exception-first views opening on delays, breaches, and blocked shipments, with the full list one click away rather than in the way.

Impact you will see

The screen leads with the work instead of with the volume.

How we work

Commitments, not promises

How we build for logistics clients. Each one is checkable in the work itself rather than a claim about results you cannot see.

Typical stack
React NativeNext.jsNode.jsPostgreSQLAWSWebSockets
  • Offline-first, not offline-tolerant

    Field apps record and queue locally, so losing signal costs nothing. Reconciliation happens on reconnect with conflicts raised rather than resolved quietly.

  • Freshness is on the screen

    Every view showing a position or a status shows when it was last updated. An old reading is meant to look old.

  • Exceptions come first

    Operations screens open on delays, breaches, and blocked shipments. Everything running to plan stays available without being in the way.

Engagement

Three ways this usually starts

Prices are not listed because they depend on scope. We quote a range after discovery, along with the specific things that would move it toward each end.

Discovery

Best before you commit

A short paid engagement that ends with a scoped plan you own, whether or not we build it. If the honest answer is that you should not build software at all, that is what the document will say.

  • Requirements and constraints captured
  • Technical and integration assessment
  • Architecture and approach outline
  • An estimate as a range, with its drivers
  • Risks named rather than implied

Project build

Best for a defined outcome

A scoped build with an agreed deliverable, run in short cycles with something you can review at the end of each one. Suited to work where the shape of the outcome is already clear.

  • Fixed scope with a change process
  • Something reviewable every cycle
  • Design, build, test, and deploy
  • Documentation and runbooks
  • Handover to your team

Dedicated team

Best for an ongoing roadmap

A small team working continuously against your priorities, with capacity you can plan around. Suited to products that keep changing rather than projects that finish.

  • Named engineers, consistent over time
  • Priorities you set each cycle
  • Direct access to the people building
  • Shared repository and tooling
  • Exit on notice, with no lock-in
Related thinking

Reading that bears on this sector

All insights
Questions

Logistics: what buyers ask us

Including the ones where the answer is no. A limit stated up front is worth more than a capability claimed now and found out later.

Where they expose an API, a webhook feed, or a file exchange, yes. Most of the effort is not the connection. It is normalising status vocabularies, because in transit means something different at every partner and delivered sometimes means loaded onto a van. We keep the original payload beside the normalised record so a dispute can be settled against what the partner actually sent.

Offline-first rather than offline-tolerant. Actions are written locally and queued, the app stays fully usable with no connection, and reconciliation happens on reconnect with conflicts surfaced rather than silently resolved. Assuming connectivity is the most common reason field logistics apps lose data.

We build the software around routing: planning interfaces, constraint capture, dispatch workflows, and the operations views. For the optimisation itself we integrate a specialist engine. Vehicle routing is a deep research area with people who have spent careers inside it, and a firm our size writing a solver from scratch would be charging you for its own education.

Yes, and it is often the highest-return work in this sector because it moves the where is my delivery question out of the phone queue. A customer tracking page needs its own access model and real restraint about which internal detail it exposes, so we design it deliberately rather than reusing the internal view with a different stylesheet.

We integrate with hardware that exposes a data interface: telematics platforms, scanner SDKs, device APIs. We do not manufacture hardware or write firmware. If your devices only report through a vendor portal with no API, establish that before scoping anything else, because it changes what is buildable.

That is a design decision with a cost attached, so we make it out loud. Sub-second updates over a persistent connection are achievable and right for an active dispatch screen. A thirty-second poll is far cheaper and entirely adequate for a customer tracking page. We would rather agree the target with you than quietly build the expensive one everywhere.

Next step

Let's talk about your logistics project

A scoping conversation costs nothing. You leave with a clear view of the approach, a budget range, and the main risks named out loud, including an honest no if we are not the right firm for this.