What to Build for a Freight and Logistics Business in the UK

For: The owner or COO of a UK haulage or freight forwarding business turning £5M–£30M a year, operating on a patchwork of spreadsheets, a legacy TMS they have outgrown, and manual check-call workflows — now facing margin pressure from fuel costs, driver shortage, and customers demanding real-time visibility they cannot provide

If you run a UK haulage or freight forwarding business between £5M and £30M in revenue, the highest-ROI custom software you can build is not a shiny customer tracking portal. It is an internal empty-leg matching engine wired into the job board and planner your traffic office already uses. Cut empty running from 30% to 20% on a 50-truck fleet and you recover more margin per quarter than any rate negotiation with a supermarket account. Everything else — POD reconciliation, subcontractor rate control, MTD-compliant invoicing — comes after that, and much of it should be bought, not built.

This post walks through the three operational problems that are actually costing UK mid-market hauliers real money in 2025, what to build for each, and the order to do it in. It also flags the things every TMS vendor will try to sell you that are not worth building yet.

The three problems that actually cost you money

Every haulier we speak to has a list of twenty things they want to fix. Most of them are noise. Three are not.

1. Empty running

UK HGVs drove empty for 31% of all mileage in 2025 — 5.9 billion kilometres of diesel, tyres, driver hours and tolls burned moving air, according to Department for Transport statistics. The figure has barely moved from 30% in 2024. For context, the EU average is roughly one empty kilometre in four; the UK sits at closer to one in three, per IPP Pooling's analysis of DfT data.

This is not a driver problem or a customer problem. It is a data problem. Planners cannot see, in the moment a job is confirmed, which trucks will be within a viable radius of the collection point on the right day with the right capacity and drivers' hours available. So they default to sending the closest truck out empty.

Kinaxia, a UK haulier, brought its empty running from 27% to 16% in 2024 using AI-driven route optimisation, per Mordor Intelligence's UK road freight report. An eleven-point reduction on that fleet is a seven-figure annual number.

2. Proof-of-delivery reconciliation

Most mid-market hauliers still chase PODs manually. Signed paper sheets get scanned at depot, emailed to accounts, matched by hand to a job number, then chased with the customer 30 to 45 days later when payment is short. Every missing POD is either a delayed invoice or a written-off line. On a business doing 4,000 jobs a month, even a 3% POD gap is a material working-capital drag.

3. Subcontractor rate disputes

If you subcontract 15–40% of your work — most UK forwarders and mid-size hauliers do — you are almost certainly losing money on the reconciliation between what you quoted the customer, what you agreed with the subbie, what actually got done, and what got invoiced. Rate variations (waiting time, extra drops, failed collections, congestion charges, ULEZ) get captured in WhatsApp messages and forgotten. The subbie invoices at the higher rate. You pay it because you cannot prove otherwise.

What to build for each — and what to buy

Problem 1: Empty-leg matching engine (build custom)

What it is: An internal tool that runs continuously against your live job board and fleet telematics. When a new job is entered, it flags matches against trucks that will be tipping within X hours and Y miles of the collection point, respecting drivers' remaining hours, vehicle type, and any customer-specific constraints (tail lift, ADR, temperature). It does not auto-assign. It surfaces options to the planner with an estimated margin uplift per option.

Why custom: Every off-the-shelf TMS has some version of this, and none of them work well because they do not know your commercial rules. Your planner knows that Customer A will accept a 90-minute delivery window flex if it means keeping the account, and Customer B will not. That logic lives in people's heads and needs to be encoded specifically for you. A generic optimiser cannot do this without months of configuration that costs more than a purpose-built tool.

What changes when it exists: Planners stop defaulting to the closest empty truck. Empty running drops by 5–15 percentage points within two quarters if the tool is actually used (this is the hard part — see the sequencing note below). Fuel spend drops proportionally. Driver hours utilisation improves without adding trucks.

What it takes: The scope model here has three drivers: (a) how clean your existing job data is, (b) whether your telematics provider (Microlise, Samsara, Webfleet, Verilocation) exposes a usable API, and (c) how many commercial rules need encoding in the first version. Build one that reads from your existing TMS and telematics rather than replacing them. Ship the planner-facing tool first; do not touch driver workflows in v1.

Problem 2: POD capture and reconciliation (build thin, buy the rest)

What it is: A lightweight driver-facing capture step (photo of signed sheet, geotagged, timestamped, tied to the job number) plus an automated matching layer that pushes complete POD packs to your invoicing system the moment the job is closed.

Why thin custom: The capture side is a solved problem — Microlise, Podfather, Descartes and half a dozen others do it well. The reconciliation and invoicing handoff is where custom pays. You want PODs matched to jobs matched to customer-specific invoicing rules (some want consolidated weekly, some per-job, some with rate confirmations attached) and pushed into Sage, Xero or whatever ledger you run, with an audit trail that satisfies HMRC's Making Tax Digital requirements. MTD for VAT has been mandatory for all VAT-registered businesses since April 2022, and manual portal submission is no longer permitted.

What changes: Days-sales-outstanding drops. Invoice queries drop. Your credit control team stops being a POD chasing team.

Problem 3: Subcontractor rate control (build custom, small)

What it is: A subcontractor portal — or, more realistically for v1, an internal tool your traffic office uses — that captures every job assigned out with the agreed rate, agreed extras schedule, and any live variations (waiting time triggered, extra drop added). When the subbie invoices, the system three-way matches invoice to agreed rate to actual events logged.

Why custom: Because no SaaS knows your subcontractor commercial terms and your dispute patterns. This is a small build — a few weeks of work if scoped tightly — and it typically pays back inside two quarters on a business subcontracting more than £100k a month.

What NOT to build yet

• Customer-facing tracking portal. Customers say they want it. What they actually want is fewer check calls. A well-configured email/SMS milestone notification from your existing TMS solves 80% of that. Build the portal in year two, once your data is clean enough to expose without embarrassment.
• Driver app with everything in it. Drivers hate apps. Add one screen at a time to whatever they already use. If you are pushing 55% of your drivers who are aged 50–65 (per Multimodal.org.uk) onto a new interface, expect turnover.
• Full TMS replacement. Do not do this. Ever. Build around your existing TMS. Replacements are 18-month projects that go 30% over and rarely deliver the promised gains. The empty-leg engine, POD layer, and subbie tool all sit on top of what you already have.
• AI-powered pricing. Not yet. You do not have clean enough historical rate and cost data. Fix data capture first.

The UK-specific constraints that generic vendors ignore

Any build for a UK haulier has to respect four things that international TMS vendors handle badly:

1. DVSA operator licence compliance. Vehicle roadworthiness records, drivers' hours, tachograph data, and management systems all need to be auditable. A Traffic Commissioner can curtail, suspend or revoke your O-licence. Whatever you build must not create a compliance gap.
2. MTD for VAT. Any invoicing or reconciliation tool must maintain digital records with the API-linked filing chain HMRC requires. This is a data architecture decision, not a feature.
3. Post-Brexit cabotage rules. If you run international, your planning tool needs to know how many cabotage movements each truck has done and when.
4. Driver shortage economics. The RHA says the sector needs 60,000 new drivers a year for five years, per trans.info, and around 110,000 drivers let their Driver CPC cards lapse in December 2024 alone, per trans.info's June 2026 report. Every hour of unnecessary driving time is more expensive than it was three years ago. This is what makes empty-leg reduction the number one build.

How to sequence it

Order matters. Doing these in the wrong sequence wastes six months.

Quarter 1: Data plumbing

Before you build anything user-facing, get your job data, telematics data, and driver hours data flowing into one place. This is unglamorous. It is also the difference between a working empty-leg tool and one your planners ignore in month three. Most mid-market hauliers have this data — it is just scattered across the TMS, the telematics portal, the tacho analysis tool, and a couple of spreadsheets.

Quarter 2: Empty-leg engine v1

Ship the planner-facing tool. Read-only from existing systems. Surface options, do not auto-assign. Measure empty running weekly and put the number on a screen in the traffic office. The measurement itself changes behaviour before the tool does.

Quarter 3: POD reconciliation and MTD-compliant invoicing handoff

Now that data is flowing, wire the POD-to-invoice loop. This is the working capital win.

Quarter 4: Subcontractor rate control

Last, because it depends on the job data discipline you built in Q1–Q2. Trying to build this on messy data produces a tool your traffic office argues with.

Year two is when you look at a customer portal, deeper AI on pricing and forecasting, and driver-facing improvements. Not before.

The cost and timeline model, honestly

The single question every owner asks is what this costs and how long it takes. The honest answer is that it depends on four things: how clean your existing data is, how many integrations you need (TMS, telematics, tacho, ledger, customer EDI), how many commercial rules go into v1, and whether you have someone internally who can own the requirements. Two hauliers of similar size can be a factor of three apart on total cost based on those variables alone.

Illustrative shape only: a 50-truck haulier with a working TMS, Microlise telematics with API access, Sage for the ledger, and a clear planner-side scope for the empty-leg tool is looking at a Q1 data project, then a v1 empty-leg tool in the following quarter, then the POD and subbie tools over the two quarters after. Every one of those assumptions moves the number.

To turn a range into a real quote, three things need scoping: (1) an audit of your current data sources and whether the APIs you need actually exist, (2) a workshop with your traffic office to encode the commercial rules that make the empty-leg engine useful, and (3) the invoicing integration shape — Sage, Xero, or something else, and what your MTD chain looks like today. Those three conversations turn guesses into commitments.

How CodeNicely can help

We built Vahak, one of India's largest road transport marketplaces, which handles load-matching, route optimisation and carrier verification at national scale. The engineering problems there — matching loads to trucks under time, capacity, driver hours and commercial constraints, integrating with telematics, and doing it fast enough to be useful to a dispatcher in the moment — are the same problems a UK haulier faces internally on their own fleet. The scale is different; the mechanics are not.

For UK freight and logistics businesses, we typically start with a two-week discovery: audit your existing TMS, telematics and ledger stack, identify which of the three problems above is bleeding the most cash for your specific operation, and scope a v1 empty-leg tool or POD reconciliation layer around what you already own. You keep the IP, you keep the code, and nothing gets built that replaces a system that is already working. More on our approach to legacy modernisation and custom software, and how we work with SMBs modernising operations.

Frequently Asked Questions

Should we replace our existing TMS or build around it?

Build around it, almost always. Full TMS replacements are 12–18 month projects that disrupt operations and rarely hit the ROI promised in the sales cycle. The empty-leg engine, POD layer and subcontractor tool all sit on top of your existing TMS and telematics. Replace the TMS only if it literally cannot expose data via API, in which case the replacement is a data project, not a features project.

What drives the cost of a custom empty-leg matching tool?

Four things: the cleanliness of your existing job and telematics data, whether your telematics provider exposes the APIs you need, how many commercial rules need encoding in v1, and whether you have an internal owner who can make requirements decisions quickly. A tightly scoped v1 for a single-depot operation is a very different build from a multi-depot, multi-customer operation with EDI feeds. Scoping those variables is what turns a range into a real quote — a conversation with CodeNicely can size it against your specific stack.

How do we stay MTD-compliant if we build custom invoicing tooling?

Any custom tool that touches VAT invoicing must maintain the digital record chain HMRC requires and file via a recognised API path — usually by pushing into your existing ledger (Sage, Xero, QuickBooks) rather than filing directly. Do not treat this as a feature; treat it as a data architecture constraint from day one. A tax adviser should review the specifics of your MTD setup before you finalise the design.

Is AI route optimisation worth it for a 20–50 truck fleet?

Yes, if empty running is above 25% and you have telematics data going back at least twelve months. Below that fleet size, the ROI on a custom build gets thinner and off-the-shelf tools become more attractive. The Kinaxia example — 27% to 16% empty running in a year — is a real UK data point for what is possible when the tool actually gets used by planners day to day.

What about DVSA operator licence compliance in custom builds?

Anything you build that touches drivers' hours, tachograph data, vehicle inspections or maintenance records must preserve the audit trail the Traffic Commissioner expects. This is not something to bolt on later. The safest path is to leave your compliance system of record (usually your TMS or a specialist tool like TruTac or FleetCheck) as the source of truth and build alongside it, not on top of it. An O-licence adviser should review the compliance boundary of any custom build.