Logistics & Supply Chain
Software engineering for Transportation
Transportation software is about vehicles in motion and the drivers behind the wheel, and both are messy in ways a dashboard hides. The value is in optimising routes and loads that reality keeps disrupting, giving drivers a tool they will actually use one-handed at a delivery, and keeping tachograph and drivers’ hours compliance right where getting it wrong risks the operator’s licence. We build for the road as it is, not the map as it looks.
Why the domain matters
Transportation is the discipline of moving physical things (vehicles, people and goods), and the software that matters is the software that copes with movement. Where a freight or supply-chain system reasons about shipments and orders, a transportation system reasons about the vehicle itself: where it is, how it is being driven, whether the driver is legal to keep going, how the day’s work should be routed and loaded, and how all of that changes the moment traffic, a breakdown or a late collection disrupts the plan. It is a real-time, operational domain where the plan is always colliding with the road, and the good software is the software that degrades gracefully when it does.
The sector has a shape worth naming, because software lands differently across it. Road-freight and haulage operators care about fleet utilisation, drivers’ hours and the operator’s licence that lets them trade at all. Delivery and field-service fleets care about routing, load planning and the driver’s experience across dozens of stops a day. Passenger-transport operators (bus, coach, rail, on-demand), care about scheduling, ticketing and giving passengers a real-time ETA they can trust. What unites them is that the asset is a vehicle in motion and the operator is a human being at the wheel, and both of those are harder to model honestly than a static order in a database.
We are a senior-led team and we operate what we build, so we start from the cab and the depot rather than from the control-room screen. The recurring failure mode in transportation software is an optimiser or a driver app that looks brilliant in the office and is unusable on the road: a route that ignores how vehicles and drivers really behave, a driver app that demands two-handed data entry at a doorstep, or a compliance module that is nearly right in a domain where nearly right risks the operator’s licence. We would rather build the tool a driver will genuinely use one-handed and the compliance logic that is exactly right than the polished map that impresses in a demo. The hard part here is the road, the driver and the regulator, not the interface.
The challenges in transportation
Optimisation that survives contact with the road
Route and load optimisation is easy to demonstrate on a clean map and hard to make useful in reality. Traffic, delivery windows, vehicle and load constraints, driver hours, curfews and access restrictions all shape a viable plan, and the plan is obsolete the moment a collection runs late or a road closes. The real challenge is optimisation that produces routes drivers will actually follow and that re-plans sensibly when the day falls apart, not a theoretically optimal answer nobody can execute.
Driver apps that work one-handed at a doorstep
The driver is the user who matters most and the one most often designed for last. They are moving between stops, often in poor signal, frequently with one hand full, and they will abandon any tool that adds friction to a day measured in minutes per drop. A driver app has to capture what it needs with the fewest possible taps, work offline and sync later, and respect that the person using it is doing a hard physical job, or it simply will not get used, however good the back office thinks it is.
Tachograph and drivers’ hours where nearly right is not enough
Drivers’ hours and tachograph rules govern how long a driver may legally drive and rest, and the operator’s licence depends on getting them right. Software that touches this cannot be approximately correct: a miscalculated rest period or a missed infringement is a compliance failure that the DVSA can act on and that puts the operator’s ability to trade at risk. This is a domain where the engineering has to be exact and the failure modes are legal, not cosmetic.
Telematics data that is high-volume and frequently unreliable
Vehicles emit a constant stream of position, speed, fuel, engine and driver-behaviour data across a mix of telematics units and standards. That stream is high-volume, arrives late or in bursts, drops out in tunnels and rural notspots, and rarely agrees between devices. Turning it into something trustworthy (an accurate position, a fair driver-behaviour score, a real fuel figure), is a serious data-engineering problem, not a matter of plotting a dot on a map.
Real-time ETAs passengers and customers will trust
A live ETA is one of the most visible things a transportation product does and one of the easiest to get embarrassingly wrong. Whether it is a passenger waiting for a bus or a customer waiting for a delivery, an ETA that is confidently inaccurate erodes trust immediately. Producing one that accounts for traffic, remaining stops, driver hours and real vehicle behaviour (and is honest about its uncertainty), is genuinely hard, and it is where naive “straight-line to destination” estimates fall apart.
Mixed, ageing fleets and hardware you do not control
An operator’s fleet is rarely uniform, different vehicles, different ages, different telematics units, tachographs and on-board hardware from different vendors, some barely supported. Software has to work across that heterogeneity rather than assuming one tidy platform, and it has to degrade gracefully when a device is offline or a vehicle predates the feature you were relying on. Assuming a uniform, fully connected fleet is a fast route to a product that only works in the brochure.
What we build for transportation
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Fleet management systems
Systems covering the operational life of a fleet, vehicles and their compliance, maintenance and defect reporting, utilisation, fuel and cost, and driver assignment. We build for mixed, ageing fleets and the reality that hardware fails and vehicles differ, because fleet software earns its keep through dependable day-to-day operation, not through a dashboard that assumes every vehicle is new and connected.
Route and load optimisation
Optimisation that respects the constraints that actually make a route viable (delivery windows, vehicle and load limits, driver hours, access and curfews), and, crucially, re-plans sensibly when the day falls apart. We build for routes drivers will genuinely follow and for graceful re-optimisation under disruption, not for a theoretically optimal answer that collapses at the first late collection.
Telematics and vehicle data
The data layer that ingests high-volume, unreliable telematics from mixed hardware and turns it into something trustworthy, accurate position, fair driver-behaviour scoring, real fuel and utilisation figures. We treat the late, bursty, dropout-prone nature of the stream as the core engineering problem, because a fleet decision made on bad data is worse than one made on none.
Driver apps
Mobile apps designed for the person at the wheel, minimal taps, offline-first with reliable sync, proof of delivery or service, walkaround checks and defect reporting, and job flow that works one-handed between stops. We design these around the driver’s real day rather than the back office’s wish list, because a driver app that adds friction is a driver app that gets left in the glovebox.
Tachograph and drivers’ hours compliance
Compliance tooling that reads tachograph data, calculates drivers’ hours correctly, flags infringements, and produces the records the DVSA expects, built to be exact, because this is the domain where nearly right risks the operator’s licence. We treat the calculation logic and the audit trail as safety-critical work, not a reporting feature bolted on at the end.
Passenger transport, ticketing and scheduling
Software for bus, coach, rail and on-demand operators, scheduling and rostering, ticketing and fares, and passenger-facing real-time information and ETAs. We build the scheduling and ticketing to cope with the real operational churn of passenger transport and the ETAs to be honest about uncertainty, because a passenger who is misled once stops believing the next prediction.
Where we help
A fleet system that works across a mixed, ageing fleet
A haulier or delivery operator wants one system for vehicles, maintenance, compliance and utilisation, but their fleet is a mix of ages, vehicles and telematics units. The real work is building software that copes with that heterogeneity and degrades gracefully when a device is offline or a vehicle predates a feature, rather than a dashboard that only works if every vehicle is new and fully connected. Done right, the operator runs the whole fleet from it; done naively, half the fleet falls outside the model.
Route optimisation drivers will actually follow
A delivery operation wants tighter routes and lower miles, but the drivers ignore the last optimiser because its routes did not reflect reality. We build optimisation that respects windows, load and vehicle constraints and driver hours, produces routes drivers trust, and re-plans sensibly when a collection runs late or a road closes. The measurable win is routes that are executed rather than overridden. A plan that survives the road, not one that only looks optimal in the office.
A driver app that gets used every drop
A field-service or delivery fleet has a back-office system but no driver tool, or one the drivers refuse to use. We build an app designed for the cab: minimal taps, offline-first, proof of delivery and defect reporting that works one-handed in poor signal, so the data the back office needs is captured without slowing the driver down. The value is measured in adoption at the doorstep, because a driver app nobody uses has captured nothing.
Drivers’ hours and tachograph compliance the DVSA will accept
An operator is managing tachograph data and drivers’ hours on spreadsheets and living in fear of an infringement being missed. We build compliance tooling that reads the tachograph data, calculates hours exactly, flags infringements and keeps the records an inspection expects: built as safety-critical logic because this is where nearly right risks the operator’s licence. The value is a compliance position the operator can defend, not a report that is usually correct.
How we build for transportation
We start from the cab and the depot, not the control-room screen. Before designing a route optimiser or a driver app we want to see how drivers actually spend a shift, what the telematics hardware really emits, and where the operational plan collides with the road. In transportation the constraint is almost always the messy reality of vehicles in motion and the human at the wheel, so we design for the driver working one-handed in poor signal, not for the demo that impresses in the office.
We are blunt about the difference between an optimal plan and an executable one. A route that is theoretically optimal but that drivers override, or that collapses the moment a collection runs late, has delivered nothing. We build optimisation that produces routes people will actually follow and that re-plans gracefully under disruption, because in this domain the value is in a plan that survives the road, not in a lower number on a screen that reality immediately invalidates.
We treat tachograph and drivers’ hours as safety-critical, exact work, resourced accordingly. This is the part of the domain where nearly right is a compliance failure the DVSA can act on and a risk to the operator’s licence, so we build the calculation logic and the audit trail with the rigour that carries, not with the looseness of a reporting feature. Being approximately right is not an option where getting it wrong can stop an operator trading.
Because we operate what we build, the people who design a driver app or a drivers’ hours calculation are the ones called when a driver abandons the tool at the doorstep or an infringement is missed. That concentrates the mind on the failure modes that actually matter (adoption in the cab and exactness in compliance), and it keeps us honest about trade-offs up front rather than discovering them in production on your behalf.
Regulation and compliance
Road transport in the UK is heavily regulated, and the obligations reach directly into the software. Operators of goods vehicles need an operator’s licence and must meet its conditions; drivers’ hours and the tachograph rules govern how long a driver may drive and must rest; and the DVSA enforces all of it, with real consequences up to loss of the licence. Where our software touches drivers’ hours, tachograph data or vehicle compliance, it has to be exact and it has to evidence what an inspection would demand: the compliance is in the calculation and the record, not a policy beside them.
Vehicle roadworthiness and maintenance carry their own regime, regular safety inspections, driver walkaround checks, defect reporting and rectification, and the records that prove them. Software that manages a fleet has to capture and retain that maintenance and defect trail properly, because it is exactly what the DVSA looks at and what an operator relies on to defend their licence at a public inquiry.
Passenger transport carries its own obligations again. PSV operator licensing, accessibility requirements, and increasingly the fare and ticketing rules of the schemes an operator participates in. And data protection under UK GDPR sits across everything, because transportation software holds personal data on drivers (including location, behaviour and hours that are sensitive), and on passengers where ticketing and accounts are involved. We engineer for lawful basis, minimisation and retention from the start, particularly around driver monitoring, which is both sensitive and easy to over-collect.
We build systems that meet these obligations, but we are engineers, not your transport-compliance or legal advisers. Operator licensing, drivers’ hours interpretation, and the responsibilities of a transport manager carry real legal weight, and sign-off rests with your own transport manager and compliance function. Our job is to build software that calculates, captures, evidences and retains exactly what those obligations require, and to work alongside the people accountable for the licence.
Integration
Telematics and on-board hardware are the gravitational centre of transportation integration. Vehicles carry telematics units, tachographs and on-board computers from a range of vendors, emitting position, speed, fuel, engine and driver-behaviour data over a mix of standards and protocols. A serious product has to ingest all of it across a mixed, ageing fleet, cope with late, bursty and dropped data, and normalise it into one trustworthy model: that ingestion and normalisation layer is a large part of the real engineering.
Tachograph data has its own integration path, downloading and reading digital tachograph and driver-card files, and feeding them into drivers’ hours calculation and infringement detection. We treat this as exact, safety-critical integration because the output drives compliance decisions that bear on the operator’s licence, not merely a dashboard, so the mapping and the calculation have to be precisely right rather than approximately so.
Mapping, routing, traffic and geocoding services feed optimisation and ETAs, and mobile networks feed the driver app: an app that has to work offline in notspots and sync reliably when signal returns. We build the driver-facing side around unreliable connectivity as a first principle rather than assuming constant coverage, because assuming a connected driver is how a field tool fails silently at the doorstep.
Back-office systems: the transport management or order source, maintenance and workshop systems, fuel-card and payment providers, and for passenger operators the ticketing and payment rails, all plug into the operational flow. The recurring engineering problem across all of it is keeping the picture of each vehicle and driver consistent and trustworthy as data crosses heterogeneous hardware and systems that were never designed to agree. We treat that reconciliation as core work, because a fleet decision is only as good as the data behind it.
Security and data protection
Transportation software holds data that is sensitive in a particular way: it tracks people. Driver location, speed, behaviour scoring and hours worked are personal data about employees, and passenger accounts and ticketing add another population again. That is both a privacy responsibility and, mishandled, an industrial-relations and legal exposure, 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.
Driver monitoring deserves the most deliberate handling. Continuous location and behaviour data on a named employee is exactly the sort of collection that becomes a dispute (or an incident), when it accumulates without purpose limitation and clear access boundaries. We design who can see a driver’s location and behaviour, and for how long it is retained, deliberately, rather than hoarding telematics history because storage is cheap and it might be useful one day.
The vehicle itself is increasingly a connected endpoint, and telematics and on-board systems are a real attack surface: a compromised fleet platform can expose the live location and movement patterns of vehicles, drivers and valuable loads. We treat the security of those connections and the platform behind them as the genuine operational and physical-safety risk it is, not as a routine web-app concern, because the consequences reach beyond data into the movement of real assets.
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 driver’s data-subject request would need, and treat the ability to reconstruct exactly who accessed a driver’s location and behaviour data as part of the deliverable, not something you find missing after a dispute or an incident.
What changes
Plans that survive the road
Because we build optimisation that respects real constraints and re-plans gracefully under disruption, routes are executed rather than overridden and the day recovers sensibly when a collection runs late, so the miles and the time actually come down in practice, not just in the office.
A driver app that gets used every drop
By designing for the person at the wheel (minimal taps, offline-first, one-handed at the doorstep), the tool captures what the back office needs without slowing the driver down, so it is used every stop rather than left in the glovebox, which is the only way the data ever arrives.
A compliance position you can defend
By building drivers’ hours and tachograph logic to be exact and fully evidenced rather than approximately right, the operator can stand behind their records at a DVSA inspection or public inquiry, turning compliance from a spreadsheet-borne risk to the operator’s licence into something defensible.
What we build for transportation
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 transportation?
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 transportation choose us
We design for the driver, not the control room
The driver is the user who matters most and the one most often designed for last. We build tools that work one-handed in poor signal between stops, because a driver app that adds friction gets abandoned, and an abandoned app has captured nothing, however good the back office thinks it looks.
We build optimisation that survives disruption
A theoretically optimal route that drivers override or that collapses at the first late collection has delivered nothing. We build routes people will actually follow and re-planning that recovers gracefully, because in transportation the value is a plan that survives the road, not a lower number on a screen.
We treat drivers’ hours and tachograph as exact, safety-critical work
This is the domain where nearly right risks the operator’s licence. We build the calculation logic and the audit trail with the rigour that carries and evidence what a DVSA inspection demands, because being approximately right is not an option where getting it wrong can stop an operator trading.
We operate what we build
The people who design a driver app or a drivers’ hours calculation are the ones paged when a driver abandons the tool or an infringement is missed. That keeps us focused on the failure modes that actually matter (adoption in the cab and exactness in compliance), and honest about trade-offs up front rather than in production.
Related sectors
Part of Logistics & Supply Chain. Adjacent sectors we also know.
Common questions
How do you build route optimisation that drivers will actually follow?
By treating executability as the point, not theoretical optimality. We build optimisation that respects the constraints that make a route viable (delivery windows, vehicle and load limits, driver hours, access and curfews), and, just as importantly, re-plans sensibly when a collection runs late or a road closes. A route that is optimal on paper but that drivers override, or that collapses at the first disruption, has delivered nothing. We aim for routes people trust and execute and for graceful re-optimisation under the real churn of the day, because in transportation the value is a plan that survives the road, not a lower number on a screen.
What makes a driver app succeed where others get abandoned?
Designing for the person at the wheel rather than the back office. Drivers are moving between stops, often in poor signal, frequently one hand full, working a day measured in minutes per drop, so the app has to capture what it needs in the fewest possible taps, work offline and sync later, and never add friction to a hard physical job. We build proof of delivery, walkaround checks and job flow that work one-handed at a doorstep, because a driver app that slows the driver down gets left in the glovebox, and an app nobody uses has captured nothing however good it looks in the office.
Can you handle tachograph data and drivers’ hours compliance?
Yes, and we build it as exact, safety-critical work rather than a reporting feature, because this is the domain where nearly right risks the operator’s licence. We read digital tachograph and driver-card data, calculate drivers’ hours correctly, flag infringements, and keep the records a DVSA inspection expects, with the calculation logic and audit trail built to the rigour that carries. To be clear about the boundary: we are engineers, not your transport-compliance advisers, so operator licensing and the transport manager’s responsibilities rest with your own compliance function, and we build to give them a position they can defend.
Our fleet is a mix of ages and telematics units, will your software cope?
Yes, and we treat that heterogeneity as a first principle rather than an edge case. Real fleets are rarely uniform: different vehicles, ages, telematics units, tachographs and on-board hardware from different vendors, some barely supported, so we build to ingest and normalise a mixed hardware estate and to degrade gracefully when a device is offline or a vehicle predates a feature. Assuming a uniform, fully connected fleet is a fast route to a product that only works in the brochure, so we build for the fleet you actually run, not the one the demo assumes.
How do you make real-time ETAs that passengers and customers trust?
By producing them honestly and being transparent about uncertainty. A live ETA is one of the most visible things a transportation product does and one of the easiest to get embarrassingly wrong, and a confidently inaccurate estimate erodes trust immediately: whether it is a passenger waiting for a bus or a customer waiting for a delivery. We build ETAs that account for traffic, remaining stops, driver hours and real vehicle behaviour rather than a naive straight line to destination, and that are honest about their confidence, because a prediction that misleads someone once means they stop believing the next one.
Building for transportation?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if transportation 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.