The idea
A planning tool for any business that runs a daily round: a bakery delivering to cafés, a florist, a lab courier, a mobile mechanic. You paste or import tomorrow's stops, set who's driving and when they finish, and press plan. Out comes an ordered route per vehicle that respects delivery windows, load capacity, and the fact that one van has to be back by two. Drivers open a phone link with their sequence; each customer gets a link showing roughly when they're next.
Why build this
The businesses in this band — fifteen to sixty stops a day, one to four vehicles — plan in a spreadsheet and the owner's head. Google Maps caps a route at ten waypoints and knows nothing about a 09:00–11:00 window. The dedicated platforms (Onfleet, Routific, Circuit for Teams) price per driver per month and bundle dispatch, telematics, and customer support nobody here asked for. Meanwhile the owner spends forty minutes every evening resequencing by hand, redoes it when a stop cancels, and fields "where is it" calls all morning.
What makes it buildable now is that the hard parts are commodity. Valhalla and OSRM run in Docker against a regional OpenStreetMap extract, so the distance matrix costs you CPU rather than per-element API fees. OR-Tools solves a sixty-stop vehicle routing problem with time windows in a couple of seconds on a laptop. OSM coverage of last-mile addressing is good enough in most of Europe and North America that geocoding is a solved problem with a human fallback.
Stack sketch
- Valhalla in Docker with a Geofabrik regional extract — matrix API for the solver, turn-by-turn for the driver view
- Google OR-Tools routing module for the CVRPTW solve, in a Python worker behind a Redis queue
- FastAPI + Postgres with PostGIS for customers, stops, vehicles, and rounds
- Pelias for geocoding, with a per-customer coordinate cache that a human can pin by hand and that is never overwritten
- SvelteKit planner UI, MapLibre GL with Protomaps tiles
- Driver view as a PWA: a service worker caches the day's stops and tiles, so the round survives a dead spot; photo proof-of-delivery to MinIO
- Customer ETA pages behind signed short-lived URLs
Scope for v1
In: CSV or paste import with column mapping; geocode with a manual pin-correction step; one depot; several vehicles each with capacity and a shift window; per-stop service time and time window; solve; drag to reorder with live feasibility checking; a driver link that hands the next leg to Google or Apple Maps; mark delivered or failed with a reason code and a photo.
Out: live GPS tracking, mid-round re-optimisation, SMS (the ETA link is enough at first), invoicing, multi-depot, multi-day planning, signature capture.
Where it could go
The obvious second release learns from itself. You are already recording when each stop was completed, so you can replace the guessed service time with the measured one per customer — the café that always takes eleven minutes stops blowing up the afternoon. That feedback loop is the thing the cheap tools don't do and it's nearly free once the completion data exists.
After that, recurring rounds become templates and a weekly schedule generates the days, which is how these businesses actually think. Then the solver is worth exposing on its own: home care visits, equipment servicing, and compliance inspections are the same problem with different nouns, and a plain HTTP endpoint that takes stops and vehicles and returns routes is easier to sell into those verticals than a whole dispatch product.
Watch out for
The distance matrix is where costs and terms bite: a sixty-stop solve needs thousands of pairwise durations, and commercial matrix APIs both charge per element and usually forbid storing the results — self-hosting the routing engine isn't an optimisation, it's the business model. The other quiet failure is rural and newly built addresses geocoding to the wrong end of a lane, which makes the whole plan silently wrong, so the manual pin step has to be in v1 rather than after the first complaint.