Industry
Software engineering for Logistics & Supply Chain
Freight software lives or dies on integration, not on the dashboard. The value is in orchestrating shipments cleanly across dozens of carriers, couriers and legacy systems, and in keeping the status you show a customer actually true from booking to proof of delivery. The dashboard is the easy 20 per cent; the carrier feeds, the EDI, the customs documentation and the honest event model are the 80 per cent that makes or breaks it. We build for that reality.
Why the domain matters
Logistics is an orchestration problem wearing an operations disguise. A single shipment can touch a freight forwarder, a road haulier, a sea or air carrier, a customs broker, a last-mile courier and a warehouse, each running its own system, its own data format and its own idea of what a “delivery” event means. The software that matters in this sector is the layer that ties those parties together: booking a movement, generating the documentation, pushing and pulling status, and presenting one coherent picture to the shipper and the end customer. None of that is glamorous, and almost all of the difficulty is in the seams between systems that were never designed to agree with one another.
The market has a shape worth naming, because software lands differently at each point. Freight forwarders sell orchestration and paperwork: they book capacity they do not own and live on rates, documentation and multi-leg coordination. Carriers and couriers own the physical movement and expose the feeds everyone else depends on. Third-party logistics providers sit in the middle running fulfilment and transport on behalf of shippers. And the shipper (the manufacturer or retailer whose goods are actually moving), mostly wants to know where their freight is, what it costs, and whether it will arrive when promised. A transport management system that works has to serve whichever of those roles your client plays, and integrate cleanly with all the others.
We are a senior-led team and we operate what we build, so we start from the integration reality rather than the pitch. The recurring failure mode in logistics software is a beautiful control tower fed by feeds that are late, incomplete or quietly wrong, so the status on the screen diverges from where the freight actually is, and once a customer catches that divergence, they stop trusting the tool. We would rather build the unglamorous carrier integrations, the EDI mapping and the honest event model that survives contact with a delayed vessel and a missing scan than the slick visibility layer that demos well over clean test data. The hard part here is never the interface. It is the integration sprawl and keeping the status truthful end to end.
The challenges in logistics & supply chain
Integration sprawl across carriers and couriers
Every carrier, courier and forwarder exposes a different interface. Some modern APIs, many EDI, some CSV feeds, a few nothing but a screen-scrape or a portal. A serious TMS or booking product has to speak to dozens of them, each with its own quirks, rate structures, label formats and status vocabularies. This integration sprawl is the actual bulk of the work, and underestimating it is the most common way a logistics build ships late and half-connected.
Keeping shipment status truthful end to end
A track-and-trace view is only worth building if it is honest. Status events arrive late, out of order, duplicated or not at all; a courier scan can be missed, a milestone assumed rather than confirmed. The engineering challenge is an event model that distinguishes what is confirmed from what is inferred, reconciles conflicting updates, and does not show a customer “out for delivery” on a parcel sitting in a depot. A confidently wrong ETA erodes trust faster than an honest “we do not yet know”.
Legacy systems that everything already runs on
Most forwarders and 3PLs already run an incumbent forwarding system, WMS or ERP that is the system of record for their whole operation, often decades old. New software has to integrate with it, migrate off it carefully, or sit alongside it, because ripping it out mid-flight stops freight moving. Any plan that assumes a clean greenfield ignores the software the operation depends on every hour of every day.
Customs and documentation that block goods at the border
Post-Brexit, GB–EU movements need customs declarations through HMRC’s CDS, commodity codes, origin, EORI numbers and the right accompanying documents, and errors do not produce a warning. They hold goods at the border and cost real money. Software that touches import or export has to generate accurate documentation and declarations, handle the data the border systems demand, and treat getting it wrong as an operational and legal exposure for your client, not just a validation bug.
Multi-leg shipments across modes and hand-offs
A container that moves road-to-sea-to-road-to-courier is one shipment to the customer but several bookings, several carriers and several hand-offs to the software. Modelling that multi-leg reality, where each leg has its own status, its own documents and its own point of failure, while presenting a single coherent journey is genuinely hard, and it is where naive tracking models fall apart the moment freight leaves a single carrier’s network.
Rates, surcharges and reconciliation that never quite agree
Carrier rates come with fuel surcharges, accessorials, dimensional weight rules and constant change, and the invoice rarely matches the quote first time. Software that books freight has to rate it defensibly and then reconcile what was charged against what was expected. Getting rating and billing wrong quietly leaks margin on every shipment, so this is where accuracy matters as much as anywhere in the stack.
What we build for logistics & supply chain
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Transport management systems
A TMS built around the orchestration reality, booking movements, rating and routing them, generating documentation, and tracking status across the carriers and legs involved. We treat the carrier integrations and the event model as the core of the system rather than a bolt-on, because a TMS whose feeds are late or whose status is unreliable is a liability dressed as a control tower.
Carrier and courier integrations
The integration layer that speaks to carriers and couriers in whatever they actually offer (API, EDI, flat file or portal), normalising bookings, labels, rates and status into one consistent internal model. This is unglamorous, high-value work: the difference between a product that connects to two carriers for the demo and one that connects to the dozens your operation really uses.
Track-and-trace and visibility
End-to-end visibility built on an honest event model that separates confirmed events from inferred ones, reconciles conflicting updates, and gives shippers and end customers a status they can trust. We build ETAs and milestones that are transparent about uncertainty rather than confidently wrong, because in this sector the credibility of the whole tool rests on the status never lying.
Customs and documentation
Software that generates the declarations and documents freight actually needs. CDS-ready customs data, commercial invoices, packing lists, bills of lading and the accompanying paperwork, with validation that catches the errors that hold goods at the border. We build this as a first-class concern because a rejected declaration is not a UI defect, it is a stopped shipment.
Last-mile and delivery operations
Last-mile software covering route and delivery management, driver hand-off, proof of delivery, and the exceptions (failed deliveries, redeliveries, returns), that dominate the real cost of the final leg. We build for the messy reality of the doorstep, where the value is in handling what goes wrong cleanly, not in the happy path that always arrives first time.
EDI and B2B messaging
EDI and B2B integration for the standards trading partners actually mandate. EDIFACT and X12 messages, ANSI transaction sets, and the bespoke variations every partner insists on. We build resilient mapping and messaging that copes with malformed partner data and reconciles acknowledgements, because in freight EDI a silently dropped message is a shipment nobody is tracking.
Where we help
A TMS that connects to the carriers you actually use
A forwarder or 3PL wants one system to book, rate and track across their carrier base rather than logging into a dozen portals. The real work is the integration layer: normalising bookings, labels, rates and status across API, EDI and file-based carriers into one model, and the honest event handling behind the tracking. Get that right and operators live in the tool; get it wrong and they quietly go back to the carrier back offices.
Track-and-trace that a customer can actually trust
A shipper is tired of telling their own customers “it is somewhere in transit”. The visibility layer pulls status from every leg and carrier, reconciles late and conflicting events, and shows a milestone view that distinguishes confirmed from inferred. The measurable win is fewer “where is my order” calls and a status page nobody has to apologise for, which only holds if the event model is built to be honest about what it does not yet know.
Customs documentation that clears the border first time
A business moving goods GB–EU is losing time and money to rejected declarations and held freight. We build the documentation and CDS-ready customs data generation with validation that catches missing commodity codes, EORI errors and origin problems before submission, integrated with the operational flow so the data is captured once. The value is measured in border rejections avoided, not screens shipped.
A last-mile operation that handles exceptions cleanly
A courier or retailer drowning in failed deliveries, redeliveries and returns needs the exception path to be first-class, not an afterthought. We build route and delivery management with proof of delivery, driver hand-off and structured handling of everything that goes wrong at the doorstep, because in last mile the cost and the customer frustration both live in the exceptions, and software that only models successful delivery solves the easy half of the problem.
How we build for logistics
We start from the integrations and the event model, not the screens. Before designing a control tower we want to know which carriers, couriers, forwarders and legacy systems the operation really depends on, what each of them actually exposes, and where the status genuinely comes from. In logistics the constraint is almost always integration sprawl and data honesty, so we design for the feed that arrives late and incomplete, not for the clean test data that makes any dashboard look good.
We are blunt about the difference between a real ETA and a comforting one. It is easy to paint a confident milestone on a map; it is honest engineering to model what is confirmed versus inferred, reconcile conflicting scans, and show uncertainty where it genuinely exists. We would rather ship a status view that occasionally admits “we do not yet know” than one that says “out for delivery” about a parcel sitting in a depot, because the first keeps a customer’s trust and the second destroys it the first time they catch it out.
We treat carrier integration and EDI as the core of the work, resourced accordingly. Connecting to dozens of carriers across API, EDI and file feeds, mapping their rates and status vocabularies, and coping with their downtime and malformed data is where these projects are won or lost. We plan for that sprawl from day one rather than discovering late (when the visibility layer is done and polished), that half the carriers do not feed it cleanly.
Because we operate what we build, the people who design a carrier feed or a customs export are the ones called when a declaration is rejected at the border or a shipment shows the wrong status to a customer. That concentrates the mind on the failure modes that actually stop freight moving, and it keeps us honest about the trade-offs up front rather than discovering them in production on your behalf.
Regulation and compliance
Cross-border freight carries obligations that reach straight into the software. Since Brexit, GB–EU movements need customs declarations, and where our software touches import or export it has to produce the data HMRC’s Customs Declaration Service demands (commodity codes, customs procedure codes, origin, EORI numbers and valuation), accurately, because a defective declaration holds goods at the border rather than raising a warning. The compliance here is in the data the border systems require, not in a policy document beside it.
Different modes carry their own documentary and safety regimes. Air freight moves under security screening and known-consignor rules; sea freight under bills of lading and container weight verification; the movement of dangerous goods under ADR and its equivalents, with strict documentation and handling requirements. Software that books or documents these movements has to capture and evidence what each regime requires, because getting it wrong is a safety and legal exposure, not a cosmetic one.
Data protection under UK GDPR sits across the operation, because logistics software holds personal data: consignee names and addresses, delivery contact details, driver information and increasingly recipient signatures and photos captured as proof of delivery. We engineer for lawful basis, minimisation, retention limits and access control from the start, particularly around the proof-of-delivery data that accumulates quietly and is easy to over-retain.
We build systems that meet these obligations, but we are engineers, not your customs, trade-compliance or legal advisers. Classification of goods, customs valuation, sanctions and export-control screening and the like carry real legal weight, and sign-off rests with your own compliance function or your customs broker. Our job is to build software that captures, validates, evidences and retains what those obligations require, and to work alongside the people accountable for them.
Integration
Carriers and couriers are the gravitational centre of logistics integration. They expose bookings, rates, labels and status in every format imaginable: modern REST APIs, EDIFACT and X12 EDI, flat files, and occasionally nothing but a portal, and a serious product has to normalise all of it into one internal model. We build resilient integrations that cope with each carrier’s quirks, downtime and malformed data rather than pretending the connection is a simple API call, because that normalisation layer is the actual product in most freight software.
The incumbent forwarding system, WMS or ERP is the other side of the problem. Most forwarders and 3PLs already run one as the system of record for their whole operation, so new software has to read from it, write to it, or migrate off it without stopping freight moving. We treat migration and coexistence as first-class engineering, because the legacy system is not going anywhere on the timescale of a single project and pretending otherwise breaks a working business.
EDI and B2B messaging tie the trading network together. Partners mandate EDIFACT and X12 transaction sets (and their own bespoke variations of them), for orders, dispatch advices, invoices and status. We build mapping and messaging that handles the standards and the partner-specific deviations, reconciles acknowledgements, and surfaces failures loudly, because in freight a silently dropped EDI message is a shipment nobody is tracking and an invoice nobody is expecting.
Customs and border systems, mapping and geocoding, telematics feeds for in-transit position, and payment and rating engines all plug into the operational flows. The recurring engineering problem across all of it is the same: keeping shipment data consistent, deduplicated and truthful as it crosses carriers, systems and borders that were never designed to agree with one another. We treat that reconciliation as core work, not an afterthought, because it is where the honesty of the whole picture is won or lost.
Security and data protection
Logistics software holds a rich and sensitive store of data: consignee names and addresses, delivery contacts, the contents and value of shipments, carrier account credentials, rates that are commercially confidential, and increasingly proof-of-delivery photos and signatures. That is both an attractive target and a serious liability, so we build with access controls scoped to genuine need, encryption in transit and at rest, and retention limited to what a lawful basis actually supports.
Carrier credentials and rate data deserve stricter handling again. Access to a client’s carrier accounts is access to book freight in their name and to see negotiated rates that are competitively sensitive, so we protect those integrations carefully, scope credentials tightly, and treat a compromised carrier connection as the direct operational and financial risk it is rather than a routine secret.
Proof-of-delivery data (a recipient’s photo, signature and address tied to a specific parcel), is exactly the kind of personal data that turns into an incident when it is captured and retained without thought. We design its collection, access and retention deliberately, narrowing who can see it and how long it lives, rather than letting delivery evidence accumulate loosely across the system because it was easy to store.
Because we operate what we build, security here is not a report handed over at the end. We instrument for the access patterns and anomalies that indicate a problem, keep the audit trail an investigation or a data-subject request would need, and treat the ability to reconstruct exactly what happened to a shipment’s data and who touched it as part of the deliverable, not something you discover missing after an incident.
What changes
One system that actually connects to your carriers
Because we treat carrier and courier integration as the core of the work rather than a bolt-on, bookings, rates, labels and status flow cleanly from the carriers you really use (not just the two that made the demo), so operators live in one system instead of a dozen portals.
Status your customers can trust
By building an honest event model that distinguishes confirmed from inferred and reconciles late, conflicting updates, the track-and-trace view stops lying (no “out for delivery” on a parcel in a depot), which cuts “where is my order” traffic and keeps the credibility of the whole tool intact.
Fewer shipments held at the border
By generating CDS-ready customs data and documentation with validation that catches commodity-code, EORI and origin errors before submission, declarations clear first time more often, measured in border rejections avoided and freight that keeps moving, not in screens shipped.
What we build for logistics & supply chain
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for logistics & supply chain?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in logistics & supply chain choose us
We treat integration sprawl as the hard part it is
Connecting to dozens of carriers, couriers and legacy systems across API, EDI and file feeds is where freight software is won or lost. We resource that from day one instead of discovering it late, which is what separates a TMS that runs your whole carrier base from one that shipped connected to two.
We keep the status honest
We build an event model that separates what is confirmed from what is inferred and reconciles conflicting updates, because a track-and-trace tool that shows a confidently wrong status loses a customer’s trust the first time they catch it. Honest visibility is the product, not the map.
We work with the legacy systems, not against them
Most forwarders and 3PLs depend on an incumbent forwarding system, WMS or ERP that runs their whole operation. We treat integration and careful migration as first-class engineering rather than assuming a greenfield, because ripping out the system of record mid-flight stops freight moving.
We operate what we build
The people who design a carrier feed or a customs export are the ones paged when a declaration is rejected or a shipment shows the wrong status. That keeps us focused on the failure modes that actually stop freight, and honest about trade-offs up front rather than discovering them in production on your behalf.
Related sectors
Adjacent sectors we also know.
Common questions
Can you integrate with our carriers and couriers?
Yes, and we treat that integration layer as the core of the work rather than a bolt-on, because it is where freight software most often ships half-connected. Carriers and couriers expose bookings, rates, labels and status in every format imaginable (modern APIs, EDIFACT and X12 EDI, flat files, sometimes only a portal), and the real work is normalising all of it into one consistent internal model that copes with their quirks, downtime and malformed data. We build for the dozens of carriers your operation actually uses, not the two that would make a clean demo.
How do you make track-and-trace status reliable?
By building an event model that is honest about what it knows. Status events arrive late, out of order, duplicated or not at all, so we distinguish confirmed events from inferred ones, reconcile conflicting updates, and show uncertainty where it genuinely exists rather than painting a confident milestone that may be wrong. We would rather a status view occasionally say “we do not yet know” than tell a customer “out for delivery” about a parcel sitting in a depot, because in this sector the credibility of the whole tool rests on the status never lying, and a customer stops trusting it the first time they catch it out.
We already run a forwarding system, WMS or ERP, can you work with it?
Almost always, and we plan for it from the start. Most forwarders and 3PLs depend on an incumbent system that is the record for their whole operation, so new software has to integrate with it, sit alongside it, or migrate off it carefully, never rip it out mid-flight, because that stops freight moving. We treat that coexistence and migration as first-class engineering, because the legacy system is not going anywhere on the timescale of a single project, and pretending otherwise is how logistics software breaks a working operation.
Can you handle customs and cross-border documentation?
Yes, as a first-class concern rather than a validation afterthought, because a rejected declaration is a stopped shipment, not a cosmetic bug. Post-Brexit, GB–EU movements need declarations through HMRC’s CDS with commodity codes, customs procedure codes, origin and EORI numbers, and we build the documentation and CDS-ready data generation with validation that catches those errors before submission. To be clear about the boundary: we are engineers, not your customs or trade-compliance advisers, so classification, valuation and export-control sign-off rest with your compliance function or your broker, and we build to work alongside them.
Do you build EDI and B2B integrations for trading partners?
Yes, and we build them to survive the real world of partner data. Trading partners mandate EDIFACT and X12 transaction sets for orders, dispatch advices, invoices and status (plus their own bespoke variations of the standards), and the difficulty is in the deviations, the malformed messages and the acknowledgements that need reconciling. We build resilient mapping and messaging that surfaces failures loudly rather than swallowing them, because in freight a silently dropped EDI message is a shipment nobody is tracking and an invoice nobody is expecting.
Building for logistics & supply chain?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if logistics & supply chain is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.