Step Out: Building an Offline AI Outdoor Break Planner with Gemma and Ollama

This project comes from the MLH x DEV writing challenge, where developer Cynthia Wahome built a local AI outdoor break planner called Step Out. It uses the Gemma 3 1B model together with Ollama to generate short outdoor activity plans on a local computer, without needing a cloud inference API.

Why an Offline AI Break Planner

"Go outside for a walk" is great advice, until you look out the window and find only concrete, parked cars, and a neighbor confidently backing into their parking spot.

For people juggling multiple roles and staring at screens all day, outdoor breaks have to fit into daily life. Maybe you only have ten minutes of free time and a familiar yard—scenic hiking trails are unlikely to appear between two meetings.

The core idea behind Step Out is straightforward: spend a little time planning, then get away from the screen. Users choose four preferences—available time (5/10/15/20 minutes), familiar outdoor space (community yard, familiar street, or outdoor seating area), goal (quiet pause, light movement, or observing surroundings), and activity preference (walking/standing or seated activity)—and the system returns an activity card with instructions, timing, and a reflection prompt.

No account registration, no handing over precise GPS location, and no streak record waiting to judge you tomorrow.

Real-World Data on Local Inference

According to the developer's testing, Gemma 3 1B runs locally on an Apple M1 laptop. A cold-start request took 7.45 seconds, and warm requests ranged from 5.45 to 7.54 seconds. These are measurements from a specific hardware environment; local inference performance depends on hardware, memory, and whatever else the computer is running at the same time.

The developer also tested a fresh generation with Wi-Fi turned off and no other network connection. Once the model and app dependencies are installed, the local app can still generate new plans. The model runs on a laptop, and the current version does not support running on mobile.

What Gemma 3 1B and Ollama are. Gemma is a family of open-weight language models released by Google, and 1B refers to the smallest version with roughly 1 billion parameters, suitable for running on consumer laptops. Ollama is a local model runtime that downloads model weights, manages memory, and exposes an OpenAI-compatible HTTP API (listening on port 11434 by default). The app only needs to send requests to a local port, with no need to compile an inference engine itself. Together, the two let developers call large models without an internet connection.

The difference between cold start and warm requests. A cold start means the model has not yet been loaded into memory and must first load its weights, so it takes longer; a warm request means the model is already resident in memory and only performs inference. Time to first token is mainly affected by memory bandwidth and model loading speed, which is why closing other programs noticeably improves the experience on an 8GB or 16GB laptop.

Actual Usage Experience

On October 9, 2026, the developer tried a ten-minute seated activity in a family compound yard, chose "quiet pause," and the generated activity was "notice outdoor sounds."

The timing was: 1 minute to prepare and reach the outdoor spot, 8 minutes observing surrounding sounds, 1 minute to return and settle back in. The instructions required no phone use, staying seated throughout, and noticing three kinds of sounds.

The break actually took 9 minutes and 30 seconds, with zero screen checks. Sitting on a stone bench listening to birdsong and ambient community noise, then returning and saving a reflection in the browser. This small break gave the project a useful reality check: when you are no longer looking at the interface, do the instructions still make sense?

Technical Architecture: How Gemma, Ollama, and the Code Divide Responsibilities

The project uses Google's open-weight model Gemma 3 1B (tag gemma3:1b), served locally by Ollama. The Next.js backend sends generation requests to the local 127.0.0.1:11434 port. Preference handling is done on the same computer, and reflections are saved in browser local storage.

There are no token fees for a paid inference API, but there are still hardware and electricity costs, and the computer's compute power is limited. "Local" does not mean "running out of thin air." The demo processes only one generation request at a time to avoid the usage limits of external providers—but avoiding quotas does not mean eliminating the app's own capacity constraints.

The Code Handles Time Calculation

The developer kept time calculation out of the model's responsibilities. The backend handles allocating 1 minute for preparation, 1 or 3 minutes for return, and the remaining time for the activity, with these phases adding up to the duration selected by the user. Gemma chooses and adjusts the activity, but it does not decide that a ten-minute break includes fourteen minutes of walking.

Before inference, the backend filters from a curated set of five activities based on the chosen space, goal, and activity preference. Seated choices exclude walking activities. These rules narrow the model's options, but they do not verify the safety of the outdoor location, nor do they prove that every generated sentence is appropriate.

Constraining Structured Output with Zod

Small models can produce plausible-looking values that are wrong for the application. For example, the activity ID seated-movement-001 looks completely normal but may actually point to something that does not exist in the catalog.

The developer used a JSON schema generated by Zod 4 to constrain the response. The available activity IDs form an enum in the response schema, passed through Ollama's format parameter. The backend then validates the returned JSON and checks whether the selected activity is in the available list. The goal is to constrain the response structure and allowed IDs while retaining application-level checks. This improves reliability, but it does not make the model's instructions universally correct, nor does it turn the generated text into a fully deterministic system.

What JSON Schema and structured output are. The default output of a large model is free text, while applications often need machine-parseable fields (such as activity ID, duration, and instructions). JSON Schema is a specification that describes data structures and value ranges, and Zod is a TypeScript-first validation library that can automatically generate the corresponding JSON Schema from TypeScript types. Ollama's format parameter accepts such a schema, restricting the model during decoding to output only tokens that match the structure, greatly reducing the probability of format errors.

Why enum validation matters. Small models may generate plausible-sounding but nonexistent IDs based on linguistic intuition. Once the available activity IDs are written as an enum, the model can only choose from a limited set; the backend then performs a second check against the real catalog, forming a dual line of defense of model constraints plus application validation.

Next.js and TypeScript

The app uses Next.js 16's App Router and TypeScript, placing the interface and API routes in the same project. The request flow is: the browser collects four preferences → the backend validates and filters the activity set → Ollama runs the local model with these constraints → the backend validates the response and adds the timing → the interface displays the activity card.

Plain CSS provides labeled controls, visible keyboard focus, and responsive layout, without relying on external stylesheets or font CDNs. Deep teal, warm cream, and a touch of terracotta accents create a calm and friendly interface atmosphere.

The Meaning and Cost of Open Weights

Open weights let developers run inference on their own hardware, keeping the local generation flow independent of hosted AI APIs. They can also choose models suited to the task, modify prompts, edit the activity set, and other developers can inspect the code and run the app in their own environments.

The cost is that developers also take on the entire environment: model downloads, available memory, slow startups, and connection errors. Gemma is used under its own model terms, and an application license cannot replace those terms.

The difference between open weights and open source. Open weights means the model parameters can be downloaded and executed locally, but the training code, training data, and terms of use are not necessarily open. Gemma uses custom Gemma Terms of Use, with clear rules on usage, redistribution, and derivative models. Therefore, an open source license at the application layer (such as MIT) only governs the code you write and cannot replace or override the model's own terms. Commercial use requires separately confirming the model license.

Development Lessons Learned

This project was completed in the first week of Hacktoberfest 2026, and the developer summarized three lessons:

Small models are useful when tasks are focused. Gemma 3 1B does not need to plan an entire life; it only needs to turn a few preferences and available activities into a short outdoor break.

Application code still has its own responsibilities. Input validation, activity filtering, time calculation, and response checking all belong to the backend. Persuasive prompts cannot replace these controls.

An app can succeed by helping users leave it. The goal is a clear plan for users to take outdoors, and staying longer in the interface would actually work against that goal.

The yard test made the project real. After debugging prompts and schemas, the developer finally followed those instructions themselves. This time, closing the laptop was part of the acceptance test.

One-line Summary

Step Out uses Gemma 3 1B and Ollama to generate outdoor break plans locally and offline, exploring a task-focused path for small models.

Paragraph Summary

Step Out is a local AI outdoor break planner from the MLH x DEV writing challenge, built by developer Cynthia Wahome. It uses Google's open-weight Gemma 3 1B model together with Ollama to generate activity plans on your own computer, without needing a cloud inference API. After users choose preferences such as time and space, the system returns an activity card with instructions, timing, and a reflection prompt—no account, no GPS, no streaks. The developer measured a cold start of about 7.45 seconds and warm requests of 5.45 to 7.54 seconds, and verified that new plans could still be generated after disconnecting from the network. Technically, the balance tips toward application code: the backend handles time calculation and activity filtering, a JSON schema generated by Zod 4 constrains model output, and the model only selects and adjusts. The author also personally tried a ten-minute seated activity, which actually took 9 minutes and 30 seconds, with no screen checks throughout.