I Built a Route Optimization System. The Algorithm Wasn’t the Hard Part.

Act I: Problem Definition and Objective Misalignment

1. "Optimize the Routes" Sounds Like a Well-Defined Problem

Byufuel sits in the middle of the used cooking oil supply chain. It collects UCO from restaurants, hotels, commercial kitchens, and other food outlets and aggregates it for downstream processing.

When we were given the task of optimizing collection routes, the first instinct was obvious:

Build a routing algorithm.

The actual problem was much less obvious.

What exactly should the algorithm optimize?

The initial problem statement framed the objective around cost and carbon emissions per litre of UCO collected. But those are not variables that a routing solver can simply minimize without additional assumptions.

We could estimate the cost of a route from its distance. We could use distance as a proxy for fuel consumption and therefore transport-related emissions. But the amount of UCO collected also mattered.

A route collecting substantially more UCO could be preferable to a slightly shorter route.

So the practical objective became:

That distinction changed how we thought about the entire problem.

We weren't just looking for the shortest route.

We were building a system that had to balance where vehicles went, what they could carry, which outlets mattered, and how much material they could collect along the way.

2. The Solver Wasn't the First Thing We Built

The first thing we needed was not an algorithm.

It was a list of rules.

The initial project brief contained broad requirements such as time windows, vehicle capacities, dynamic pickups, traffic, and the requirement to serve all vendors.

But each of those requirements had to become something the optimization model could actually understand.

For example:

• "Vehicles have different capacities." → Became: Each vehicle has its own capacity constraint.
• "Some restaurants are more important." → Became: Priority had to be encoded explicitly.
• "A new pickup can arrive during the day." → Became: Re-solve the routing problem for the remaining unserved restaurants.
• "Routes should account for traffic." → Became: Generate a separate navigation route for each vehicle so the driver receives a route that incorporates live traffic conditions.

This translation was the real engineering work.

Act II: Translating Operations into Constraints

3. Turning Fleet Operations Into Constraints

The final system had to represent several pieces of operational reality simultaneously.

Heterogeneous vehicles

The fleet was not homogeneous.

Different vehicles had different carrying capacities and operational characteristics. A routing solution therefore could not simply treat every vehicle as interchangeable.

The solver had to decide which vehicle should serve which collection points while respecting each vehicle's capacity.

Time windows

Collection was not possible at arbitrary times.

The MVP incorporated pickup time windows, including the general operating window and outlet-specific restrictions where applicable. The solver therefore had to produce routes that were not only geographically feasible, but temporally feasible.

Priority outlets

Priority turned out to require more nuance than simply assigning a numerical weight.

We ended up with two levels:

• Two-star outlets: Must be served first.
• One-star outlets: Must be served that day, but can be served at any point during the day's routes.

This is a good example of something that looks like a small business rule but has a direct effect on the mathematical formulation. "Priority" wasn't a label in a spreadsheet anymore. It became a constraint on the sequence of visits.

4. The Carbon Problem We Couldn't Pretend to Solve

Objective Ratio: (kg CO₂ emitted) / (litres of UCO collected)

But that requires a reliable relationship between every route and its actual fuel consumption. We did not have that.

Fuel consumption depends on vehicle characteristics, traffic, driving behaviour, road conditions, and other factors. Treating all of those as known would have created a much more sophisticated model, but not necessarily a more truthful one.

So we made the modeling assumption explicit:

That meant the optimizer could work with something measurable and available rather than creating false precision around an emissions model we did not have the data to support.

Act III: CVRPTW Formulation and OR-Tools Engine

5. What the Optimization Problem Actually Became

Once the operational rules were formalized, the problem fit naturally into a Capacitated Vehicle Routing Problem with Time Windows (CVRPTW).

Objective Function and Constraints:

• Minimize total fleet transport distance while maximizing collected UCO volume.
• Respect vehicle capacity bounds $Q_k$ and customer time windows $[t_i, t_j]$.

At a high level, the solver receives:

• Collection locations
• Estimated UCO volumes
• Available vehicles and capacities
• Depot locations
• Pickup time windows and outlet priorities

It then has to construct a set of vehicle routes that serve the required outlets while respecting capacity and time limits.

The algorithmic machinery was Google's OR-Tools. Once the problem was formulated correctly, this part was surprisingly straightforward.

6. Then We Had to Deal With the Real World

A solver can return a perfectly valid route that a human operator would never want to use.

This became obvious during the demos. Operators cared about things that weren't obvious from the optimization formulation:

1. KPI Headers First: Operators did not want to inspect a long list of stops. They wanted the answer immediately: How much UCO is expected? How long will it take? How full will the vehicle be?
2. Vehicle Selection Thresholds: For smaller collections under a specific threshold, a moped was preferable. Above that threshold, a larger vehicle was used.

7. Dynamic Pickups and Traffic Navigation

Instead of trying to manually patch an existing route when a new pickup arrived during the day, we treated a new pickup as a new optimization event—re-solving for the remaining unserved locations.

For navigation, the system generated a separate Google Maps route link for each vehicle driver.

That gave us a clean separation of responsibilities:

• The optimizer decides where the vehicle should go.
• The navigation system decides how the driver should get there right now.

Act IV: Operational Adoption and Lessons

8. Changed Belief