Slow Mode: the laziest way to go outside

A developer built Trailhead, a local-first Streamlit app that generates short outdoor outing cards using live weather and daylight data from Open-Meteo and a locally running Gemma 3 4B model via Ollama, with output constrained to a JSON schema and validated with Pydantic. The app's Slow Mode preset pre-fills every decision — a 15-minute walk to the nearest green space — to eliminate planning entirely, and cards export as printable HTML or PDF with a local SQLite journal for offline access.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady https://dev.to/challenges/hacktoberfest-week3-2026-10-19 . Trailhead is a local-first Streamlit app that turns a few taps into a short outdoor outing. You pick an activity, how long you have, and where you are; it pulls live weather and remaining daylight from Open-Meteo, then asks a locally running open-weight model — Gemma 3 4B via Ollama — for an "outing card": a plain-language route, what to look and listen for this week, three off-screen challenges, and a one-line safety note. The card exports as printable HTML or PDF. For Week 3, I asked the sloth question: what if the app made every decision, and the correct answer was "less"? So in this story Trailhead gets Slow Mode : one button that refuses to let you plan anything. Meet Theo — invented, but you know him. Theo will spend forty minutes choosing a podcast for a twenty-minute walk. He has 6,412 unread emails and a browser with 31 tabs, three of which are "best walking routes near me." He does not need another planner. He needs a planner that quits early . Slow Mode is that. One click and it picks the lowest-effort option for every field: a walk no gear , 15 minutes the floor , the nearest green space , and a card whose only instruction is "walk to the end of your street and back. That's it." Then it drops him on the "Take me outside" screen — a single line, a return time, and no UI to get lost in. The whole product becomes a permission slip to do almost nothing. The challenge asks how much effort the project actually saves. In the story, Theo timed his old routine against Slow Mode: | Task | Before | With Slow Mode | |---|---|---| | Choosing an activity | 4 min | 0 | | Picking a route | 6 min | 0 | | Checking the weather | 2 min | 0 automatic | | Deciding when to leave | 3 min | 0 return time set | | Total | ~15 min | 1 click | Fifteen minutes of deliberation replaced by one click and a piece of paper. Theo's review, invented but plausible: "I wanted to argue with it and there was nothing to argue with." The real payoff isn't the minutes. It's that the app has no settings to fiddle with in Slow Mode — nothing to optimize, no feed to scroll, no "just one more tweak." It ends the planning by removing the choices. In the story: Theo opens Trailhead, hits Slow Mode , and gets a card for a 15-minute walk to the end of his street. The printer makes one page. He takes it, walks for fifteen minutes, and comes back. The app never asks him for an account, a rating, or a streak. The engine real . Slow Mode isn't a separate model — it's the same engine with the decisions pre-filled. The model is constrained to a JSON schema and validated with Pydantic, so the output is structured rather than prose I have to parse: response = client.chat model=OLLAMA MODEL, default: gemma3:4b messages= {"role": "system", "content": SYSTEM PROMPT}, {"role": "user", "content": prompt} , format=OUTING CARD JSON SCHEMA, Ollama constrains generation options={"temperature": 0.3}, data = json.loads response.message.content card = OutingCard data Pydantic validates Slow Mode the story's idea . It's a preset plus a stricter prompt: pick the smallest outing, the nearest green space, and exactly one thing to notice. slow = UserInput activity=Activity.WALK, time available minutes=15, location name=nearest green space lat, lon , card = generate card slow, prompt variant="smallest possible outing" Everything else real . Open-Meteo's geocoding and forecast APIs are free and keyless, so the only network call carries a city name or a coordinate. fpdf2 renders the PDF, render html gives a print-CSS fallback, and SQLite keeps a local journal so past cards stay readable offline. Stack: Python 3.15, Streamlit, httpx, the official ollama client, Pydantic, fpdf2, SQLite. No Node, no build step, no custom JavaScript. For a tool built around doing less, open matters in four very practical ways: ollama serve . There's no signal required at the moment the app is supposed to get you out the door. OLLAMA MODEL changes the brain in one env var. If you want a faster, dumber model for a 15-minute walk, that's a legitimate choice — and it's yours to make. The open part is why the app can be this boring. There's no growth team to satisfy. I'm entering Best Use of Gemma — every card is generated by Gemma 3 4B running locally through Ollama, constrained by a JSON schema and validated with Pydantic.