Rumbo

what the user sees upon entering the page

Inspiration

Let´s face it, gig drivers in Monterrey face a tough deal: a few seconds to accept a dispatch offer, with zero context about traffic, weather, or whether it'd be more profitable to wait for a second nearby order. We wanted to see what dispatch would look like if the decision-making lived with the driver's own device, and if it kept doing that reliably even when connectivity is unreliable, which happens often during Monterrey's seasonal storms.

What it does

Rumbo is an edge-first dispatch system for gig delivery couriers. It runs the entire decision loop(matching drivers to orders, calculating routes, evaluating whether to batch two nearby deliveries, and reacting to live disruptions like flooding or traffic) locally, on a Raspberry Pi, instead of a remote data center. Clients place real orders from a web app, couriers get assigned and navigate with live street-routed telemetry, and a judge-facing Command Center can inject live conditions (rain, flooding, congestion) to show the system adapting in real time. For strategic decisions, Rumbo optionally consults Google's Gemini, but every proposal passes through a deterministic validator before it's allowed to affect a real driver, and if Gemini or the network is unreachable, the same validated logic falls back to a local rule-based policy automatically, with zero interruption to the driver.

How we built it

An edge-first backend (FastAPI on a Raspberry Pi) where the core dispatch loop never blocks on a network call. A two-layer AI dispatcher: Gemini proposes a strategy, and a deterministic validator checks it's actually feasible with real order IDs, a driver who's free, sane time and profit numbers, etc. before it's allowed to execute. If Gemini or the network is unreachable, the same validated logic runs locally instead, automatically.

Challenges we ran into

Getting the Raspberry Pi set up as a real edge server was harder than it sounds, with actions such as configuring it to host the backend reliably, stay reachable on a live network with several other devices, and wire in every external API (Gemini, OSRM, TimescaleDB) around that constraint. The bigger challenge, though, was learning to treat Gemini's output as something to constrain, not just consume. Getting a response from the model was easy; getting it to make the decision we actually needed was not. That became our real prompt-engineering process: write a prompt, watch it fail in a specific way during testing, tighten the prompt or the validator around that exact failure, and test again.

Accomplishments that we're proud of

Getting multiple independent devices, for example, two clients, a driver, and a judge dashboard, to connect to the same running application and see the same live state, all synced through a single Raspberry Pi acting as the one source of truth, definitely, as well as participating in our first in-person hack.

What we learned

-How to run a WebSocket server on a Raspberry Pi that keeps multiple devices in sync locally, without depending on any cloud service to coordinate them. -How to configure and wire in an external AI API from scratch, and how to debug a distributed system effectively when something breaks. -That prompt engineering is empirical, not theoretical, as we learned to write prompts based on the actual failures we observed, not on how we assumed the model would behave: find what broke, then debug it deliberately, one iteration at a time.

What's next for Rumbo

Strengthen the server infrastructure so it holds up outside a demo environment, reach out to local businesses to register real restaurant and order data instead of simulated orders, and run a small-scale pilot with real users to surface the failure modes that only show up with real people, not simulated ones.