Detour: take the long way to a bakery (Touch Grass, powered by open-weight AI)

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Detour is a tiny web app for people who take the same route every day. You enter where you usually start and where you usually go. Detour finds the fastest route, finds a different one, and looks for a bakery near it. An open-weight model then writes a short, friendly nudge to take the new way today.

The idea is simple: you're not going on an adventure, but a new street, new shops and a bakery on the way still reset your head. The screen is the shortest part of the experience. It takes thirty seconds, and the rest is a walk or ride outside.

I made Detour to keep the adventurous side in people alive, even on days when they can't make a long trip. A student with a full timetable can't go hiking on a Tuesday, but a different street on the way to the bakery costs almost nothing. Small changes like that give me a bit of mental freshness, and that's the kind of "touch grass" I wanted to make easy.

It's for students and commuters like me who could do their route with their eyes closed. One honest note: Detour doesn't know your real habit, so "usual route" means the fastest route the router finds.

Demo

Live app: https://detour-h6dv.onrender.com
(It runs on a free server that sleeps, so the first load can take up to a minute.)

Video:

Taking it outside: I haven't walked a detour specifically for this project yet, but I study at SJCE in Mysuru, so I know these streets well. I tested the app on routes around campus, and the detour it suggested matched a route I've actually taken to a bakery before, so I could tell the new route made sense and the bakery was really on the way. Next I want to take one of the suggested detours on foot and notice what I'd normally miss.

Code

nouman004 / detour

Detour

Take a different way to the same place. Detour finds a fresh route, a bakery on it, and (with reviews connected) a dish worth trying. Built for the Hacktoberfest Open-Source AI Challenge, Week 1 ("Touch Grass").

• Routes: OpenStreetMap, Nominatim, FOSSGIS routing, Overpass (all free)
• Text: open-weight Gemma 4 first (OpenRouter and Google AI Studio at once), then open-weight models on Groq (gpt-oss, Qwen) as a safety net. The page shows which model wrote each message.
• Reviews (optional): Google Places API
• Server: one small Node file, no dependencies. API keys stay on the server.

Run locally

export OPENROUTER_API_KEY=your-key
export GEMINI_API_KEY=your-key
export GROQ_API_KEY=your-key
export PLACES_API_KEY=your-key   # optional
npm start

Open http://localhost:3000

Deploy on Render

New Web Service, connect this repo, Build Command empty, Start Command npm start, add GEMINI_API_KEY, GROQ_API_KEY and OPENROUTER_API_KEY (and optionally PLACES_API_KEY) under Environment.

View on GitHub

How I Built It

• Maps and routes: OpenStreetMap data. Nominatim finds places, FOSSGIS routing builds the routes, Overpass finds bakeries, and Leaflet draws the map.
• Server: one small Node file with no dependencies, hosted on Render. It keeps API keys off the page and calls the models.
• Open-weight models: the server tries Gemma 4 first (through OpenRouter and Google AI Studio at the same time). If that fails, it tries open-weight models on Groq. The page shows which model wrote each message. If every model is busy, a built-in line is used, and the app says so.

What went wrong first. My first version ran a small Qwen model inside the browser. It meant a 350 MB download before anyone got a route, and the text it wrote was garbled, so I moved the model behind a server.

Gemma's free tier struggled. During testing, its endpoints mostly returned 429, 500 or 503 errors, or timed out. Most of my messages ended up coming from Qwen on Groq. Groq had also retired the model names I'd hardcoded, so the server now asks Groq which open models are available instead of guessing.

What didn't make it. My original plan was to read a bakery's Google reviews and recommend its top dish. Google only provides reviews through a billing-enabled API key, so the app links to the bakery's reviews instead. That's the next thing I'd build.

I used an AI assistant to help write and debug the code.

What I Learned

• Keep the screen short. The app only works if it takes thirty seconds. Every extra step before the route made the idea weaker, which is why I dropped the 350 MB in-browser model.
• Free services fail, so plan for it. Gemma's free endpoints often returned errors or timed out. Building a fallback chain (Gemma, then Groq models, then a built-in line) taught me to design for failure from the start instead of adding it later.
• Don't hardcode things that change. Groq retired the model names I'd used, so I made the server ask which open models are available.
• Be honest about limits. Detour can't know your real habit, and Google reviews needed a billing key, so I wrote those limits down instead of hiding them.
• Working with open data. I learned how OpenStreetMap, Nominatim, Overpass and routing fit together to get from two place names to a map, a detour and a nearby bakery.
• Deploying a real app. I learned how a free Render server sleeps and wakes, and how to keep API keys on the server and off the page.

Why Does Open Innovation Matter?

• I could swap models without touching the app. When Gemma was overloaded, the same code asked Qwen or gpt-oss instead. With a closed API, one vendor having a bad day would have meant no app.
• It costs nothing to run. Free hosting plus free open-model endpoints is the whole bill.
• Less of my data leaves. The model only sees the bakery's name and the trip's extra minutes, never where you live or go. (The place search itself goes to OpenStreetMap's Nominatim.)
• The trade-off is real. Free hosted open models are rate-limited. But because the weights are open, several providers serve them, and that gave me a fallback chain.

Prize Categories

• Best Use of Render