The daily route planner: stop crossing town twice before lunch
The same class of solver the per-driver products run, on your own box, with real arrival windows for customers
- Real service durations per job type, measured over about ten jobs each - a plan built on a 30-minute guess when the work takes 90 is worse than no plan
- Every customer address geocoded once and stored; the public OpenStreetMap geocoder allows a maximum of one request per second and requires you to cache results and credit OpenStreetMap
- A machine with roughly 5x the map file in RAM for the one-off preprocessing (Belgium 659 MB, Germany 4.5 GB as of 06/08/2026) - your laptop overnight is fine, the server that answers queries needs far less
- Drivers who are told why the order is what it is, and who can push a stop back when a site is shut - a plan handed down as an order gets ignored by week two
- An odometer baseline before you start, because the kilometre saving is the half of the claim you have to prove yourself
Version history
The same solver the commercial route planners run, on your own box, for the price of a small server. Plus the honest part nobody sells you: which half of the saving is certain and which half you have to measure yourself.
The problem
Three vans, fifteen stops each, and the stops are in the order the phone rang. So the first van crosses town at 10:00 and crosses back at 14:00, and the customer who asked "what time will he be here?" got told "somewhere in the afternoon". Two costs, and they are different in kind. The certain one: somebody spends 30 to 45 minutes every morning putting stops in a sensible order, which is 2.5 to 4 hours a week of a person who could be quoting work instead. The uncertain one: the kilometres. Every vendor will quote you a percentage here. Ignore all of them until you have measured your own.
The software that fixes this is priced per driver, forever. Route4Me's Route Optimization tier is $60 per user per month with a five-user minimum, so $300 a month whether you have three drivers or five, and features like customer text notifications and avoidance zones are $20 per user each on top (verified from their published pricing, March 2026). Routific is a flat $150 a month. OptimoRoute runs $35 to $44 per vehicle per month. For a three-van operation that is roughly €1,300 to €3,600 a year, every year, to sort a list.
The engine that does the actual sorting is free and open source, and it is the same class of engine several of those products are built on. What you are paying for is hosting, a phone app and support. This blueprint replaces the first, uses a browser for the second, and is honest that the third is now you.
The architecture
▼
[ Geocoding — ONCE per customer, then cached forever ]
│ address → lat/lon, stored on the customer record
▼
[ VROOM — the solver (self-hosted, Docker) ] <— the engine
│ asks OSRM: how long from every stop to every other stop
▼
[ OSRM — road network of your country (self-hosted, Docker) ]
│ built once from an OpenStreetMap extract
▼
[ n8n — the wiring ]
├─ one ordered stop list per van, as a link on the driver's phone
├─ arrival window emailed or texted to each customer
└─ leftover jobs flagged: these do not fit today
Rerun at 11:00 with the emergency call added. It takes milliseconds.
Two containers do the thinking and one does the plumbing. The split matters: OSRM knows the roads and nothing about your business, VROOM knows your constraints and nothing about roads. Swap either one later and the other is untouched.
Tool choices — and why
VROOM (BSD-2-Clause, 1.8k stars, last push 11/05/2026) is the solver. It handles the constraints a real day actually has, not just "shortest loop": time windows per job, service duration per job, driver breaks, van capacity, skills so the gas-certified job only goes to the gas-certified van, a cap on tasks or travel time per vehicle, and multiple depots. It returns a plan in milliseconds, which is the property that matters most — replanning at 11:00 after an emergency call is free, so the plan stays true all day instead of becoming a morning artefact. One thing to know up front: VROOM is maintained by Verso, who also sell a commercial hosted API. The open-source engine is the real engine, not a crippled demo, but the project's own README is clear that self-hosting means you own the infrastructure.
OSRM (BSD-2-Clause, 8.0k stars, pushed 05/08/2026) provides the travel-time matrix VROOM asks for. Two honest numbers. First, preprocessing memory: the working rule is roughly 5× the size of the map file, and Geofabrik's country extracts today are Belgium 659 MB, Netherlands 1.3 GB, Great Britain 2.0 GB, Germany 4.5 GB (checked 06/08/2026). So Belgium preprocesses in about 3-4 GB and Germany wants 20 GB plus. Second, and this is the part that saves you money: preprocessing is a one-off you can run on your laptop overnight, then copy the built files to a small server. The server that answers queries needs a fraction of that. Do not rent a 32 GB box for a job you do four times a year. Take a country extract if you work nationally, a regional one if you do not.
Nominatim (GPL-3.0, 4.4k stars, active) or Photon (Apache-2.0, 3.0k stars, pushed 31/07/2026) turn a written address into coordinates. For a small business, do not self-host either one on day one. You geocode a customer once, when you first add them, and store the result. A few hundred customers at OpenStreetMap's public Nominatim, which allows a maximum of one request per second and requires you to cache results, send a real User-Agent and display attribution, is an afternoon of a script running quietly. Self-host later if your list grows into the thousands or you would rather no address ever leaves your building.
n8n (Sustainable Use License, free for internal business use, 200k stars, active) is the wiring: pull the jobs, call VROOM, format the stop lists, send the customer messages. If you already ran another blueprint here, it is on the same box already.
Monthly cost. Software €0 across the whole stack. Hosting: one VPS at roughly €5-15/month depending on how much RAM the served region needs. Maps €0, from OpenStreetMap. SMS is the only pay-per-use item and is optional — email arrival windows cost nothing. Against $300/month for a three-van Route4Me plan, the payback on a weekend of setup is under a month.
Setup outline
1. Download the OpenStreetMap extract for your country or region from Geofabrik.
2. On your laptop, run the three OSRM Docker steps — extract, partition, customize — against the car profile. This is the slow part. Belgium takes minutes, Germany takes hours.
3. Copy the built .osrm* files to your server and start osrm-routed in MLD mode. Test it: ask for a route between two addresses you know and check the drive time against reality. If it says 12 minutes and you know it is 25, stop here and fix it before anything else.
4. Start VROOM alongside it using the project's Docker setup, pointed at your OSRM. Send it a hand-written job list of five stops and read the output route.
5. Geocode your existing customer list once, one request per second, and write the coordinates onto the customer records. Never geocode the same address twice.
6. Model the day honestly: real service duration per job type, real van start and end points, real driver break, real time windows for the customers who have one. A plan built on a 30-minute default when the job takes 90 is worse than no plan.
7. Build the n8n workflow: jobs in, VROOM call, one stop-list link per driver, customer arrival windows out, unassigned jobs flagged back to you.
8. Run it in parallel with your current method for two weeks. Compare on odometer readings and on how often the plan survived contact with the day.
Pitfalls — the real ones
The wrong pin is silent. A geocoder that puts a rural address on the wrong side of a village produces a plan that looks perfectly sensible on screen and sends a van 20 km wrong. Nothing errors. Check every new customer's pin on a map the first time, and treat any address without a house number as unverified until someone looks.
OSRM answers 100 locations by default. --max-table-size defaults to 100, so a matrix over about 100 stops fails until you raise it. Raise it deliberately, because the matrix cost grows with the square of the stop count.
Garbage durations in, garbage plan out. The single biggest quality lever is not the solver, it is whether your service durations are real. Measure ten jobs of each type before you trust the numbers you typed in.
Do not promise a time you cannot hit. Send the customer a window, not a minute. VROOM's arrival times assume free-flowing roads — the open-source stack has no live traffic. In a city, pad it.
Drivers will route around you. If the plan is handed down as an order with no way to say "that one's shut until 10", it gets ignored by week two. Give them the reason for the order and a way to push a stop back.
The map goes stale. Rebuild the OSRM data a few times a year, otherwise the new bypass and the closed bridge are only in your driver's head.
Attribution is not optional. OpenStreetMap data is ODbL. If a customer sees a map or a route from this, credit OpenStreetMap.
Verified repos
VROOM — BSD-2-Clause, 1.8k stars, active (May 2026)
vroom-docker — BSD-2-Clause, 121 stars, active (March 2026) — the deployment path
vroom-express — BSD-2-Clause, 83 stars, last push October 2025. A thin HTTP wrapper bundled by vroom-docker; quiet because its job is small, not because it is abandoned. Check it yourself before you rely on it.
OSRM — BSD-2-Clause, 8.0k stars, active (August 2026)
Photon — Apache-2.0, 3.0k stars, active (July 2026)
Nominatim — GPL-3.0, 4.4k stars, active (August 2026)
n8n — Sustainable Use License (free self-hosted internal use), 200k stars, active (August 2026)
Get the next blueprint as it publishes — free, practical, verified tooling only.
Subscribe · Want this audited or extended for your business? DM @RXed_EU
Get this blueprint tailored to your business — free
Tell us what you run and where. We research your sector's specifics — rules, tools, customer habits — and send you a version of this blueprint rebuilt for your situation, usually within 24 hours.