Fixology builds logistics software for UK hauliers, couriers and 3PLs: planning and dispatch boards, driver apps with offline proof of delivery, customer tracking portals and the integrations that join your TMS, telematics and accounts. A dispatch and ePOD system typically takes 12 to 18 weeks, with the first drivers using it within about two months. A senior UK team builds it in two-week sprints, and the code and hosting are in your name from day one.
Where TMS and telematics packages stop being useful
Most UK operators already run a transport management system such as Mandata, Microlise or Descartes, a telematics platform like Samsara, Webfleet or Teletrac Navman, and Xero or Sage for the accounts. Each one is good at its own job. The trouble is the gaps between them, which get filled by people.
A typical traffic office will take an order from a customer email, key it into the TMS, look up the vehicle position in a separate telematics screen, phone the driver to check hours, then chase the paper POD a week later so accounts can close the job. If you are a pallet network member, the same consignment gets entered again into the Palletways, Pall-Ex or Palletforce system.
None of that is a reason to throw the TMS away. It is a reason to connect it properly and to build the one or two screens your planners actually live in. And if you run fewer than 10 vehicles on straightforward work, a packaged TMS with built-in ePOD will usually do the job; we would tell you that rather than propose a build. Our guide to bespoke versus off-the-shelf software sets out where the line usually falls.
Software we build for hauliers, couriers and 3PLs
- Planning and dispatch boards that show orders, vehicles, trailers and drivers on one screen, with drag and drop allocation, live positions from telematics and warnings when a load breaks a weight, hours or delivery window rule.
- Driver apps for Android rugged devices or drivers' own phones: job list, walkaround checks, barcode scans, photos, signatures and delivery notes.
- Customer booking and tracking portals so shippers can book collections, print labels, track consignments and download PODs without ringing your office.
- Dock and gatehouse booking for warehouses, so inbound hauliers book a slot, the gatehouse checks them in by registration, and the yard team sees what is arriving in the next hour.
- Subcontractor job sheets and self-billing for the third-party hauliers you use on busy weeks.
- Warehouse bolt-ons next to a WMS such as Mintsoft, Peoplevox or CALIDUS, for returns, labour planning or activity reporting by client.
Most of these are web applications used in the office, paired with a mobile app for drivers or warehouse staff.
Proof of delivery that works in a dead spot
Loading bays, basements and rural farm drops are exactly where mobile signal disappears, so an ePOD app has to work fully offline. The driver completes the drop, captures the signature, photos of the goods and any damage, and the app stamps the time and GPS position. Everything syncs when the phone finds a signal, and the office never sees a half-finished record.
The operational point is speed. When a POD lands in the system the moment the driver leaves, the office closes the job the same day instead of waiting for paperwork. It also settles disputes: a timestamped photo of three undamaged pallets ends most claims in one email.
We test driver apps on the devices your drivers use, with gloves on where that matters, and with the phone in aeroplane mode for half the testing.
Getting value from tachograph and telematics data
The operator licensing guide expects operators to download data from the vehicle unit at least every 90 days and from driver cards at least every 28 days, and to keep drivers' hours records for at least 12 months. Most firms do this through a tachograph analysis service, which is fine for compliance but sits apart from planning.
The useful build is joining that data to the plan. If the planner can see a driver's remaining driving time before allocating a late collection, you avoid the infringement rather than reporting it afterwards. The same goes for walkaround defects: a defect reported in the driver app can open a job for the workshop and take the vehicle off the planning board until it is signed off.
Samsara and Webfleet both offer APIs, so live positions, ETAs and driver behaviour scores can flow into your own screens and customer notifications without anyone exporting spreadsheets.
EDI, pallet networks and customer integrations
Large shippers rarely want to use your portal. They send orders as EDIFACT or XML messages, CSV files over SFTP, or calls to their own API, and they expect status updates and PODs back in the same format within minutes. Pallet networks have their own consignment systems and label formats, and each network hub expects data on its own schedule.
We build a small integration service that sits between all of them and your TMS or planning board. It receives each message, checks it, turns it into a job, and sends delivery events back automatically. Every message is logged, failed messages are retried, and a named person gets an alert when something needs a human, so you find out about a missing order before the customer does. This is the core of our API integration work, and it is often the first thing we build for an operator because it removes the most rekeying.
Driver data, UK GDPR and security
Logistics systems hold a lot of personal data about drivers: locations, hours, driving behaviour, licence details and sometimes photos. Under UK GDPR that needs a clear purpose, a privacy notice drivers have actually seen, and retention rules that delete data when it is no longer needed. If drivers use their own phones, the app should only track location during working hours, and a data protection impact assessment is usually the right starting point.
We build with access restricted by role and depot, every change logged, data encrypted in transit and at rest, and hosting in your own cloud account in UK or EU regions. Customer portals get independent penetration testing before launch. Our security page sets out how we handle hosting, access and backups on every build.
Example: a regional haulier with 40 vehicles
Here is a hypothetical but typical brief. A haulier with 40 vehicles and two depots runs an older TMS, Webfleet trackers, paper PODs scanned in the office, and Xero. Two administrators spend most of the morning matching PODs to jobs before anything can be closed.
A sensible first phase would be a driver app with offline ePOD, a feed of completed jobs back into the TMS, and an automatic draft invoice in Xero when the POD arrives. Phase two might add a customer tracking portal, using Webfleet ETAs, so customers stop phoning to ask where their delivery is.
Notice what is not in the first phase: replacing the TMS. If it holds the orders and customer accounts reliably, we build around it and leave it alone.
Why operators choose Fixology for transport software
Our aim is to be the UK's leading logistics software development company, and we judge that by what happens on the yard, not in the meeting room. Every project starts with a discovery phase that includes time in the traffic office, a ride in the cab, and a look at the real exports from your TMS and telematics. It ends with a written specification and a delivery plan you can hold us to.
The build runs in two-week sprints with a working demo on a test link at the end of each one. Driver apps go out to two or three drivers on one route first, then the depot, then the fleet. A senior UK team writes the code, which sits in your own repository from day one, with hosting in your name. After launch we stay on to support and improve the system, and because you own everything, you are never locked in. Our how we work page covers each stage in more detail.