Delivery routing for a 6‑vehicle fleet in Bogotá

The short version

Around 200 deliveries a day, 6 vehicles and a tough city. I built a custom engine on Bogotá’s real street map that decides which vehicle goes where, and in what order. Today it’s a pilot-ready demo: the map is real, and deliveries are sample data until the client’s arrive.

Context

The idea came from a friend. The business belongs to his family: a distributor with 6 vehicles making about 200 deliveries a day in Bogotá, looking to grow its freight work. The question was simple: how much are we losing by planning routes by hand?

The problem

• Routes get planned by hand every morning, based on the dispatcher’s experience.
• Badly written addresses cost extra trips.
• When a customer isn’t home, the driver improvises.
• There’s no way to compare today’s dispatch against an optimized plan.
• They want to grow without buying more vehicles.

The approach

Operating cost first, code second. The obvious move was Google’s distance matrix. I ran the numbers: for 200 daily deliveries it would cost about USD 3,600 a month, without traffic. That eats the savings the system is supposed to deliver. So the engine is custom, built on open data, and a paid traffic API is reserved for critical stretches only.

No shortcuts that kill the deal. No scraping, no reverse-engineering Google or Waze. It breaks their terms, and a serious client won’t buy something that could stop working tomorrow. Live traffic comes from three legitimate sources: the vehicles’ own GPS, a paid API on critical stretches, and driver reports.

Savings are sold as a range. Never as a fixed number before measuring with the client’s data.

What I built

• A routing engine on Bogotá’s OpenStreetMap data. 81,923 intersections, one-way streets, 4,554 traffic lights and terrain elevation. It builds the full daily plan in about 5 seconds. If a customer isn’t home, it re-plans in milliseconds.
• An address auditor. It checks every address against the city cadastre’s open house-number layer. On a test with 13 public addresses, it got 11 right. Nominatim, the most common free alternative, got 5. It reads the customer file in whatever shape the company already has it.
• A dispatcher view. Each vehicle’s route on the map, color-coded, with stop order.
• A driver view on the phone. Opens Google Maps or Waze through their official links, marks delivered or not home, and is shared with a QR code. Location sharing is optional.
• A cost projection. Fuel, hours, failed deliveries. The assumptions live in a file the client can edit.

Demo and status

• Status: pilot-ready demo.
• Tests: 405 automated tests and 86 browser tests, all passing.
• Simulation: with sample deliveries on the real map, the engine drives 12 to 23% fewer kilometers and takes 8 to 14% less time than two manual dispatch methods.
• What’s missing: 2 or 3 days of the client’s real deliveries, to audit their addresses, run the engine on their operation and recalculate the projection with their costs. Real savings get confirmed by measuring for 2 to 4 weeks.
• Version 2 for the pilot: persist the day’s progress in a database, deploy over https so phone location works, and add plate-based driving restrictions, vehicle capacity and agreed delivery windows.

What I learned

• The first version was a useful mistake. The project started as a test inside my agent office, on made-up data. I stopped it. A routing engine without the real map and verified data helps nobody. I rebuilt it on official sources: 29 verified data points and 18 explicitly marked as unverified.
• There’s no provable optimum for 200 stops. What you can do is measure how far you are from a bound, and say so.
• The right model for each piece. I used different models depending on difficulty: the strongest for the engine, cheaper ones for research, the auditor and the cost model. I reviewed every delivery with tests and screenshots.

What broke and how I found it

• The free geocoder got 5 of 13 addresses right. I tested 13 public Bogotá addresses. Nominatim, the usual free option, placed 5 correctly. Checking against the city cadastre’s open house-number layer placed 11. That test is why the address auditor exists.
• The first version ran on made-up data. It started as an experiment inside my agent office, with invented deliveries and no real map. I stopped it and rebuilt on official sources: 29 verified data points and 18 explicitly marked as unverified.
• The obvious API would have eaten the savings. Google’s distance matrix for 200 daily deliveries costs about USD 3,600 a month. I found it by running the numbers before writing the engine, which is why the engine is custom and the paid traffic API is reserved for critical stretches.

Running your own fleet?

If you deliver with your own vehicles and plan routes by hand, let’s talk. With two or three days of your deliveries, I can show you what your operation looks like on the map.

Message me on LinkedIn