This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.
What I Built
My sister is working toward a personal challenge: 20,000 steps a day.
She lives in Astana, where cold weather and a busy workday can make that harder than it sounds. Sometimes she has a short break. Sometimes she needs groceries or wants to go out for dinner. MEGA Silk Way is within walking distance of her workplace, giving her an indoor walking option—provided she has enough time to get there and back.
I built get those steps in around a question:
“How can I fit a walk into the day I already have?”
It’s a mobile-friendly web app where users enter their step goal, steps completed, available time, and the purpose of their outing. They can choose indoor or outdoor preferences and, in live mode, describe what they want in their own words.
For example:
“I have 30 minutes, would prefer somewhere warm, and don’t want to buy anything.”
The planner considers round-trip travel, time spent at the destination, and a buffer. It also offers a place to record completed walks.
The daily goal provides context, but the interface includes a reminder I wanted my sister to see:
“No need to do them all now.”
Demo
The app separates Sample and Live modes.
Sample mode uses explicitly illustrative places, route measurements, and weather. It lets visitors explore the interface without sharing their location. It does not call the model, and navigation is disabled for sample routes.
Live mode connects the planner to external place, routing, weather, and model services. It distinguishes a validated AI selection from a basic fallback rather than silently presenting fallback behavior as AI.
The three main views are:
- Plan a walk: enter time, steps, purpose, and preferences.
- Suggested plan: review the itinerary, estimates, and navigation links.
- Completed walks: record the outing’s steps, duration, and enjoyment.
The public demo is hosted on Vercel.
Code
The project uses Next.js, React, TypeScript, and Zod. It does not require an account or a database.
How I Built It
My first idea was much bigger: automatic activity tracking, Apple Watch integration, reminders during social-media use, and bus-and-walk journeys.
I narrowed it to a browser-based planner my sister could open when she wanted to move.
That decision meant accepting some useful boundaries. A browser app cannot directly read Apple Health, so step counts are clearly marked “Entered manually.” The current version focuses on pedestrian outings, with more complicated integrations left for later.
What Gemma actually does
The AI integration uses Google Gemma 3 4B IT, configured through Amazon Bedrock with the model identifier:
google.gemma-3-4b-it
The application makes two small server-side model calls.
First, Gemma interprets the optional written request into structured preferences: the outing’s purpose, indoor or outdoor preference, whether to make it longer, and whether to avoid purchases or reduce outdoor time.
Second, it selects from route candidates that the application has already checked.
The model cannot supply coordinates, route measurements, or step counts. It must return a valid candidate identifier. Its explanation is also constrained to supported facts about that candidate.
If the response fails validation, the application reports a basic fallback. If interpretation fails, it does not pretend to have understood the written request; the visible form controls still apply.
I wanted open AI to have a clear job in the finished product: turning a personal request into a choice among feasible outings.
Routes and calculations
The live integration uses 2GIS Places to discover destinations and 2GIS Routing to calculate pedestrian journeys.
Outward and return routes are calculated separately. The time budget includes:
Walking there + walking back + activity or indoor allowance + buffer
The default buffer is three minutes. Dinner and grocery outings also reserve time for the activity itself.
The application checks listed opening hours. MEGA Silk Way suggestions require confirmed opening hours and include the outdoor journey in both directions.
Indoor navigation has a deliberate limit: the app offers an approximate indoor walking allowance, but does not invent corridor distances or indoor step counts.
Weather and steps
Open-Meteo supplies feels-like temperature, wind, and precipitation for live planning. Weather is useful context, but it cannot tell us whether a particular pavement is icy or otherwise safe.
Step estimates are calculated from routed walking distance and an editable assumed step length. They are approximate, not watch measurements.
Completed-walk logs stay separate from the manually entered daily count, preventing a logged outing from silently being counted twice.
Why Does Open Innovation Matter?
Gemma is an open-weight model, available under Google’s Gemma terms.
For this project, that gives me options for how the AI component can evolve. I am using hosted inference for the demo, but the model’s weights are available for other deployment approaches. The application also keeps the endpoint and model configuration separate from the planning logic.
I have not demonstrated that Gemma produces better recommendations than a closed model, and I am not claiming that this hosted demo runs offline.
The benefit is control over the model choice and the application behavior around it. I can inspect the preference schema, restrict what the model is allowed to return, and change the integration without redesigning the walking planner.
The open-weight model powers a real part of the experience: interpreting what the user wants and selecting a suitable outing.
Privacy and Honest Limits
The browser stores preferences and walk logs. The application does not persist locations, route searches, or written requests as user history.
Live planning still uses external services. Mapping services receive the information needed to calculate routes, and the model provider processes the optional written request. Users should avoid putting addresses or sensitive information into that text field.
This is a prototype with clear boundaries:
- No automatic Apple Health syncing.
- No real bus integration yet.
- No precise indoor navigation.
- No guarantee of a different return path.
- No claim that estimated steps match a wearable exactly.
The repository includes validation tests and browser-test configuration. Live service access and physical-phone navigation handoff require separate verification; the presence of an integration in the code is not proof that every provider or device scenario has been tested.
What I Learned
The hardest design decision was deciding how much to leave out.
A system that monitors everything could take a long time to become useful. A planner that answers one question—“What walk fits right now?”—has a much clearer starting point.
I also learned to separate interpretation from calculation. Gemma can understand a preference like “somewhere warm without buying anything.” Route data and application code should establish whether the outing actually fits.
Building around my sister made those details concrete. A mall suggestion is only helpful if she can get there, walk, and return before her break ends.
What’s Next?
My next step is to test real outings with my sister and compare the suggested timing with what actually happens.
I want to learn whether the buffer is enough, whether the destinations are appealing, and whether the interface is quick enough to use during a break. That feedback will guide the next version before I add more integrations.
Prize Categories
Best Use of Gemma
The project integrates Gemma 3 4B IT through Amazon Bedrock to interpret walking preferences and select among validated route candidates.
Top comments (0)