Logistics software built around the margin hiding in the miles.
TMS platforms, fleet optimisation and shipper–carrier collaboration — engineering for an industry priced in cents per kilometre.
- Network walk and constraints
- One lane, end to end
- Widen and measure
- Rollout and adoption
- Operate to SLOs
Logistics margins live in utilisation.
Logistics margins live in utilisation: empty miles, idle docks, manual re-keying between systems that don’t talk. We build the systems that close those gaps — including our own Order & Supply Management platform connecting shippers and carriers on one planning and execution layer.
The hard part is that the plan meets the physical world. A route is not a line on a map; it is a driver with hours left on the tachograph, a trailer type that fits half the docks on the lane, a customs document that must exist before the truck reaches the border, and a receiving bay that only opens between two and four. Software that optimises without those constraints produces a plan the dispatcher overrides by lunchtime, and once dispatchers start overriding, the system stops being the record of what is happening. Every design decision we make in this sector is aimed at keeping the plan and reality in the same system.
The economics are unforgiving too. Margin per load is thin and measured per kilometre, so a platform has to pay for itself in fuel, utilisation or headcount that stopped re-keying — not in a slide about visibility. And the people using it are drivers in a cab, clerks on a yard and planners with four screens: connectivity drops, gloves are on, and nobody has time for a twelve-field form. Adoption is an engineering requirement here, not a change-management afterthought.
Four areas we work in.
We build in this sector as a services team and we offer a TMS for shippers and carriers to plan and execute on.
Transportation management
Planning, execution and settlement on Order & Supply Management — route optimisation aimed at empty miles. Orders become loads, loads become tenders, tenders become awarded moves with an agreed rate, and every status change from pickup to proof of delivery lands on one record. Settlement runs off that record, so the freight invoice is checked against what actually happened rather than against what was ordered.
Fleet & telematics
Vehicle data pipelines, utilisation analytics and maintenance signals — decisions from data the trucks already produce. Position, ignition, fuel, temperature and driver-hour feeds arrive in a different shape from every vendor, so we normalise them once, keep the raw feed for audit, and build the analytics on the normalised layer. The useful output is rarely a live map: it is loaded-kilometre share per asset, dwell by site, and the maintenance signal that arrives before the breakdown.
Shipper–carrier collaboration
Portals and APIs that replace phone-and-fax tendering with structured, auditable flows. Carriers see the lanes they are eligible for, bid or accept at an agreed rate, and confirm through a portal. The shipper gets a defensible award trail: who was invited, who answered, what it cost and why that carrier won.
Warehouse & yard systems
Dock scheduling, cross-dock flows and WMS integrations that keep goods moving instead of waiting. A dock appointment is only useful if the transport plan and the warehouse plan agree on it, so we bind the slot to the load and let both sides see the consequences of moving it. Gate-in, gate-out and trailer state are captured where they happen, on devices that work when the yard has no signal.
What we build, in detail.
Tendering that stops being a phone call.
In many networks the day starts with a planner working a list and a phone. Lanes are offered in the order the planner remembers, rates are agreed verbally, and the only record is a spreadsheet updated after the fact. We replace that with a structured tender: loads are grouped into offers, routed to the carriers eligible for the lane by contract, rate band and scorecard, and answered in a portal. Awards can be automatic inside agreed rate and performance limits, and everything outside those limits escalates to a human with the reason attached. The saving is rarely dramatic on one load; it is the compounding effect of covering lanes without a round of phone calls, and of not paying a spot rate because a contracted carrier was not asked.
- Eligibility by lane, equipment, certification and scorecard — so the offer list is defensible, not habitual
- Automatic award inside agreed rate and performance bands; everything else escalates with the reason recorded
- Answers accepted through the carrier portal, with acknowledgements tracked
Optimisation that respects the constraints.
An optimiser that only knows distance and cost will happily produce a route no driver can legally run. The work in this sector is encoding the constraints that make a plan executable — driving and rest limits, dock windows, equipment and temperature requirements, dangerous-goods restrictions, site access rules — and then letting the planner see which constraint is binding when the result looks wrong. We keep the rules readable and versioned rather than buried in the solver, so a change in a customer’s receiving hours is a configuration change, and every plan carries the rule version it was produced under. Planners keep the override, because they should; the difference is that the override is recorded and becomes evidence about which rule was wrong.
- Constraints written as readable, versioned rules — not hard-coded inside the solver
- Every plan shows the binding constraint, so an odd result is explained rather than distrusted
- Overrides recorded with actor and reason, then fed back into the rules that keep producing them
Visibility that comes from the vehicles, not from phone calls.
Ask a typical network where a load is and the answer involves someone calling a driver. The data usually exists — the truck has a telematics box, the warehouse scanned the pallet, the carrier’s own system knows the ETA — but it sits in four estates that were never joined. We build the join: feeds normalised into one event stream on an event backbone, matched to the load, and published once so customer notifications, the planning board, the exception queue and the warehouse all react to the same fact. Because it is an event log rather than a set of point-to-point calls, a carrier feed that goes quiet for an hour produces a backlog that clears itself, not a gap nobody notices. Late or corrected data replays instead of being re-keyed.
- Telematics, scan and carrier-API feeds normalised once, with the raw payload kept for audit
- One matched event per load consumed independently by notification, planning, exception and billing flows
- Freshness measured and alerted on, so a silent feed is an incident rather than a discovery at month end
Three businesses, one engineering problem.
Freight you buy, not freight you drive.
For a manufacturer or retailer the fleet belongs to someone else, and the questions are procurement questions: are we using contracted capacity before the spot market, are we paying the rate we agreed, and is the service level we promised our own customers being met. We build the tendering, execution and settlement layer that answers them from the record rather than from a monthly report, and connect it to the ERP that keeps the ledger.
- Contracted capacity offered first, spot only as a recorded exception
- Freight audit against the executed move, not the original order
- Service level measured per lane and per carrier, on numbers procurement can defend
Assets that earn while they move.
For an asset owner the number that matters is the share of kilometres run loaded, and everything else is downstream of it. We build the planning, backhaul and driver tooling aimed at raising that share: better sequencing, a backhaul search before a return leg is confirmed, and a driver app that works with one hand and no signal. Maintenance and fuel data joins the same record, so cost per kilometre is a live figure rather than a quarterly reconstruction.
- Backhaul search on every empty return leg before the plan is confirmed
- Offline-tolerant driver app — status in a few taps, photo proof of delivery, queued and synced
- Fuel, toll and maintenance costs matched to trips for a real cost per kilometre
Many customers, many systems, one lifecycle.
A forwarder’s problem is heterogeneity: every customer sends orders differently, every carrier answers differently, and margin depends on knowing which customer is actually profitable at the load level. We build the intake layer that normalises orders from API, portal and email into one order model, then run a single load lifecycle across it, with cost and revenue captured per move so the margin question has an answer per customer, lane and month.
- Order intake normalised across API, portal and file drops into one model
- One load lifecycle regardless of how the order arrived or which carrier executes it
- Cost and revenue captured per move, so margin is reportable by customer and lane
The estate a logistics business actually runs on.
ERP
SAP S/4HANA, Microsoft Dynamics and equivalent ERP systems for orders, shipment cost and invoices over IDoc, OData or REST — the ERP keeps the ledger, the transport layer runs the moves
WMS & yard
Pick readiness, ASN and dock appointment exchange so the warehouse plan and the transport plan agree on the same slot
Telematics & FMS
Position, ignition, fuel, temperature and driver-hour feeds normalised across vendors, with the raw payload retained for audit
Customs & e-documents
Customs broker endpoints and electronic freight and invoice documents, with the submitted artefact kept on the audit trail
Fuel, tolls & maintenance
Card, toll and workshop transactions matched to trips and assets to produce a defensible cost per kilometre
Freight marketplaces
Spot capacity search and posting through partner APIs, used as a recorded exception when contracted capacity is exhausted
Data warehouse & BI
Operational events exported to Snowflake, BigQuery or your lakehouse with Power BI models on top, built by data engineering
The habits we bring to a logistics engagement.
- Optimisation with operational constraints — driver hours, dock windows, equipment. The constraint set is agreed with planners before a solver is written, kept readable and versioned, and every plan records which rules produced it.
- Telematics integration across messy real-world estates. We assume partial, late and malformed messages, so unmatched traffic is queued and visible instead of discarded, and every feed is validated against the source before anything downstream depends on it.
- Offline-tolerant mobile for drivers and yards. Actions, including proof of delivery, queue locally and sync when signal returns. Flows are designed for one hand, gloves and a cracked screen, then piloted with real drivers before rollout.
- Event-driven architecture for real-time visibility. Facts are published once on a Kafka backbone and consumed independently, so a slow consumer becomes a backlog rather than a lost update, and corrections replay instead of being re-keyed.
- Settlement reconciled to the executed move. Anything that carries money — accessorials, detention, fuel surcharge — is derived from recorded events with a traceable calculation, so a disputed invoice is a report rather than an argument.
- Contracts before code at every boundary. Interfaces to ERP, WMS, telematics and carrier systems are versioned and contract-tested in CI, which is what lets product teams ship without waiting on the estate — see integration & API development.
- Observability from the first sprint. Traces across the event backbone, freshness and lag alerts per feed, and latency budgets on the screens planners use all day, because a slow planning board is an operational problem.
- Region-pinned data handling, KVKK and GDPR compliant. Driver and location data is personal data. Residency, retention and access rules are design inputs, documented for auditors rather than reconstructed for them — see security & compliance.
From the network walk to the second lane.
Network walk and constraints
We ride the process with planners, dispatchers and a driver, map the systems of record and their protocols, and agree what may not move. The output is a written integration map, the constraint set, and the one flow that is costing the most today.
One lane, end to end
A single lane or site runs the full lifecycle on real integrations — order in, tender, execution, proof of delivery, settlement. Small but real: production connectivity, real message shapes, real drivers. This is where the constraint set meets the road and gets corrected.
Widen and measure
More lanes, more carriers, the optimiser tuned against your own historical plans, and the baseline measured properly so the saving can be argued in your numbers rather than ours. Where a legacy TMS is being replaced, the two run in parallel and outputs are compared move by move.
Rollout and adoption
Site by site, with the driver and yard apps piloted before each wave and a named superuser on each site. The measure of success is that the phone stops ringing about load status.
Operate to SLOs
Dashboards, feed freshness alerts and incident handling against agreed SLOs, with cover to the hours the run contract sets. The constraint set and the optimiser are re-tuned regularly against what actually happened, at a rhythm agreed with you.
Frequently asked questions
Neighbouring sectors we work in.
Bring us a problem from your industry.
Describe what is going wrong today. An engineer reads it and replies in writing with a concrete path.