Freight Optimization Software: How uRoute Cuts Carrier Costs 15-30%
By Domenic DiNatale
Freight brokerage is a margin business. The broker's job is to match shipments to carriers — choosing among rates, transit times, service areas, equipment availability, and contractual relationships — and the difference between the best carrier and the next-best one is real money on every load. Done by hand, over a portfolio of thousands of shipments a month, those small differences accumulate into the difference between a profitable broker and one that isn't. uRoute is freight optimization software we built to make those decisions automatically — a transportation management system that turns the load-to-carrier match from a clerical job into a computational one, and reliably delivers 15-30% freight cost reduction in broker operations.
This is how it works.
The Problem With Manual Matching
A typical freight broker handles hundreds to thousands of shipments per week. For each shipment, the broker (or a coordinator) has to evaluate available carriers along multiple dimensions: contracted rates versus spot-market rates, lane familiarity, equipment compatibility, current capacity, transit time commitments, performance history, contractual minimums and maximums, and any number of relationship-specific considerations. The matching is non-trivial in the same way bin-packing is non-trivial — the locally optimal choice for one shipment frequently degrades the optimum for the next.
In practice, manual brokers default to heuristics. They go to the same carriers they've used for the same lanes before. They stop searching once they find an acceptable rate rather than the best one. They lose sight of contractual minimums until they're underutilized at the end of the month. They miss the cross-shipment optimizations that only become visible when you can see the full pipeline at once. None of this is a sign of incompetence — it's the predictable consequence of trying to solve an N-dimensional optimization problem by hand under time pressure.
Software is better at this kind of problem. The constraint is building software that the operations team will actually use, that integrates with the rest of the broker's stack, and that produces decisions the team can audit and override when their domain knowledge contradicts the algorithm. uRoute is that software.
The Architecture
uRoute is structured as a multi-module Java/Gradle platform. A shared library holds the domain models — carrier, lane, relationship, rate, order — along with the optimizer logic. A REST backend, built on JAX-RS (Jersey), is the API surface the rest of the platform calls. The operations-facing web application is built on Grails (Groovy on the JVM), where dispatchers, account managers, and operations teams do their work. The real-time channels — carrier check-ins, in-transit updates, exception alerts — run on a serverless WebSocket layer hosted on AWS Lambda. A common test harness covers regression tests for the optimizer and the rest of the platform.
The data layer is MySQL 8 with a custom DAO layer rather than a heavyweight ORM. That choice was deliberate: the access patterns in the optimizer are query-shape-specific in ways that ORM-driven query generation does not handle well, and freight brokerage data has reference patterns (carriers, lanes, relationships) where the cost of a generated N+1 query at decision time is unacceptable. We pay the cost of writing DAOs by hand and get queries that match the access patterns.
Deployment is on AWS Elastic Beanstalk, with the WebSocket layer running on Lambda. The deployment posture is ordinary — the architectural decisions that matter are upstream of where the bytes run.
The Optimizer, Conceptually
The optimizer is the heart of the platform, and the part that's interesting to talk about. It is a small, focused subsystem inside the shared domain library, called from the API when an operations user requests a recommendation for a load or a batch of loads.
The thing that makes the optimizer effective is that it does not pretend the freight matching problem is a clean optimization problem. In a textbook, you'd write down a cost function, list constraints, hand it to a solver, and consume the solver's answer. In a production freight broker, that approach fails because the cost function is not stable: a carrier's "real" rate depends on the lane, the equipment, the current contract minimum status, the recent performance history, and a half-dozen relationship-level factors that the operations team understands but that don't reduce cleanly to a single number.
So the optimizer is structured as a chain of evaluators, each of which takes a candidate carrier and a load and produces a score along one dimension. Rate evaluation. Lane familiarity. Equipment fit. Service-area coverage. Contract status (am I close to a minimum, over a maximum, in a penalty bracket). Recent performance. Each evaluator is independently configurable per broker tenant — a broker who weights on-time performance heavily can dial that evaluator up; a broker who lives or dies on rate can dial that one up. The composite score is the weighted combination, and the optimizer presents the top candidates to the operations user with the per-dimension scores visible so the user can see why the system ranked the carriers in the order it did.
That last property — the user can see the ranking rationale — is what makes the system trustable in production. A black-box optimizer that says "use carrier X" is something operations teams override into ineffectiveness within a month. An optimizer that says "carrier X scored highest on rate, second on lane familiarity, third on equipment, with low contract risk; carrier Y scored equivalently except weaker on rate" is something operations teams build trust with and rely on.
The 15-30% freight cost reduction we see in customer outcomes is the cumulative effect of consistently picking better-by-the-evaluators carriers across a full portfolio. No single decision moves the needle. Hundreds of consistently better decisions per week, applied over months, do.
Real-Time Visibility With WebSockets
A TMS that finishes its job at the moment of dispatch is not a TMS — it's a load board. The platform has to track shipments in transit, surface exceptions in time for the operations team to act on them, and update the carrier and customer pictures continuously as conditions change. We do that through uroute-socket-api, the AWS Lambda-based WebSocket layer.
The serverless WebSocket pattern fits this use case well. The event volume is high but bursty (most connections are quiet most of the time, with bursts of activity during dispatch and arrival windows). The connection lifetimes are long but cheap (carriers connect when they go on-shift and disconnect at end-of-shift). The cost model matches the workload — pay per connection minute and per message rather than per provisioned server. Putting this layer on Lambda rather than long-lived servers cleans up the operational picture and matches the cost shape of the activity.
Multi-Tenancy, Rate Management, and the Stuff That Isn't Glamorous
A TMS that serves freight brokers has to be multi-tenant from day one. Different brokers have different rate structures, different carrier relationships, different contractual obligations, and (importantly) different competitive positions that they do not want exposed to other brokers. Tenant isolation is not optional — it is the product. Every database access is tenant-scoped. Every API call carries tenant identity that flows down to the data layer. The optimizer's evaluator weights are per-tenant. The carrier and lane models are per-tenant. Rate sheets are per-tenant.
Rate management itself is a substantial subsystem. A broker's rates are not a single number per lane — they are a structure that varies by equipment type, by tonnage band, by accessorial charges, by date range, by fuel surcharge mechanism, by minimum and maximum charge floors and ceilings. Modeling this faithfully is half the data layer. Getting the optimizer to consume it accurately is most of the rest. There is no clever shortcut. The work is the work.
Security and Supply-Chain Discipline
The build pipeline runs SpotBugs (static analysis), Trivy (vulnerability scanning), and Gitleaks (secret detection) against every change. None of these are exotic tools — they are commodity. What matters is that they are wired into the standard build, that failures break the build, and that exceptions require deliberate decisions rather than quiet skips. Freight brokerage involves a lot of cross-system integration with carriers, customers, payment providers, and government systems. Every one of those integrations is a place a credential could leak. The build-time discipline is the floor of a defensible posture.
What This Bought
uRoute's customers are freight brokers, and the metric that matters to them is the line on the P&L. The 15-30% freight cost reduction we report is what shows up there: better carrier choices, multiplied by hundreds of decisions a week, multiplied by months. It is also worth noting what the metric does not measure but the platform also delivers: faster cycle time on load assignment, better visibility into in-transit status, fewer exceptions that escape the operations team's notice, and an optimizer-as-coach effect where the system makes the team's domain knowledge visible by surfacing it on every decision.
If you are running freight brokerage at scale and trying to do it on spreadsheets and a load board, the math eventually catches up with you. Freight optimization software like uRoute is what the math looks like once it's automated. We built it on Java, Grails, JAX-RS, AWS Lambda, and MySQL because those are the right tools for this domain. The 15-30% number is the consequence.
Related work from our team:
The project narrative lives on the uRoute case study page. For context on how we think about designing systems where small consistent decisions beat occasional heroics, see Human Error Is Predictable. Cascading Failure Is Optional..