This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.
π± What I Built
Most apps are designed to make journeys more efficient.
SIDEQUEST is designed to make the journey itself worth noticing.
You already have somewhere to go.
Your college.
Your train station.
Your home.
A friend's place.
SIDEQUEST takes that ordinary journey and turns it into a tiny real-world adventure.
You tell it:
- where you're going
- how much time you have
- how you're feeling
- what interests you
Then the AI gives you one small mission that fits the journey.
Not a travel itinerary.
Not a list of places.
Not another feed to scroll.
A sidequest.
For example:
Find one detail on your route that you've probably walked past before.
Or:
Take the quieter street and notice three different textures on the buildings around you.
Or:
Find a local food smell you wouldn't normally follow and discover where it comes from.
The important part comes after the AI finishes.
You put the phone down.
The intended loop is:
PLAN β GET QUEST β LEAVE PHONE β EXPERIENCE WORLD β RETURN β REFLECT
That is the product philosophy behind SIDEQUEST:
The best outcome is not more screen time.
The best outcome is that you stop using the app.
SIDEQUEST is built for people who already have somewhere to be, but don't want to sleepwalk through the journey.
What makes it different?
The AI isn't the destination.
It's the excuse to go outside.
SIDEQUEST combines:
- personalized quest generation
- multiple AI-generated candidates
- deterministic quest ranking
- safety filtering
- anti-repetition checks
- feedback-based personalization
- a field journal
- exploration statistics
- Chaos Mode for unplanned adventures
- local AI support through Ollama
And the entire UI is built around one idea:
make the screen useful for a few seconds, then get out of the way.
π₯ Demo
Try SIDEQUEST
The public demo lets you:
- Enter your destination
- Choose your available time
- Pick your mood
- Choose your interests
- Generate a SIDEQUEST
- Put your phone down
- Complete the real-world mission
- Return and reflect
The local version goes one step further: Gemma can run through Ollama directly on the laptop, so the core generation path can work without internet access.
π» Code
The repository contains the frontend, FastAPI backend, AI generation pipeline, safety filtering, ranking logic, personalization system, SQLite database layer, and local Ollama integration.
βοΈ How I Built It
Step 1: Start with the real problem, not the AI
I didn't start by asking:
"What can I do with an LLM?"
I started with:
"What if an app was successful when you stopped looking at it?"
Most digital products optimize for engagement.
SIDEQUEST deliberately optimizes for departure.
That constraint shaped the architecture, the UI, and even the way the AI generates quests.
Step 2: Make the AI generate experiences, not recommendations
A normal recommendation system might return:
"Visit this cafe."
That's not what SIDEQUEST is trying to do.
The AI receives structured journey context:
destination + available time + mood + interests
and turns it into a small actionable experience.
The output follows a structured quest format containing things like:
- title
- duration
- difficulty
- category
- objective
- steps
- novelty score
- safety notes
This gives the rest of the system something predictable to validate and rank instead of blindly displaying raw model output.
Step 3: Generate candidates, then choose
One of the important design decisions was not accepting the first AI answer.
SIDEQUEST generates multiple candidate quests.
Those candidates then move through a pipeline:
Journey Context
β
Context Builder
β
Open-Weight AI
β
Candidate Quests
β
Validation
β
Safety Filter
β
Anti-Repetition Check
β
Quest Ranking
β
Final SIDEQUEST
The ranking layer considers factors such as:
- time fit
- personalization
- novelty
- feasibility
- historical preference
- recent repetition So the LLM proposes possibilities. The application decides which one makes the most sense.
Step 4: Don't let the model decide what's safe
An AI-generated activity can sound harmless while still being a bad idea in the real world.
SIDEQUEST therefore has a separate safety filtering layer.
Generated quests are screened for things such as:
- unsafe roads
- dangerous activities
- trespassing or private property
- unsafe wildlife interaction
- phone-dependent activities
- other inappropriate instructions The important architectural choice is that safety isn't left entirely to the model. The model generates. The application validates.
Step 5: Make repetition harder
A generative model can produce ten different sentences that all describe the same experience.
That becomes annoying very quickly.
So SIDEQUEST keeps track of previous quests and checks new candidates for semantic similarity.
If a new quest is too close to recent experiences, it can be rejected and regenerated.
Recent category usage also affects ranking so the system has an incentive to vary the type of experience.
The goal is:
Not another quest.
A different experience.
Step 6: Let the system learn from the person
Personalization shouldn't mean asking users to fill out a giant profile.
SIDEQUEST learns from what happens after the quest.
When you return, you can say:
- completed
- partly completed
- skipped You can also give a rating and write a reflection. That feedback updates a lightweight personalization profile. Over time, the system can learn things such as:
- which categories the user tends to enjoy
- preferred difficulty
- preferred duration
- how much novelty they respond to
So the loop becomes:
GENERATE
β
EXPERIENCE
β
REFLECT
β
LEARN
β
GENERATE BETTER
Step 7: Chaos Mode
Sometimes planning is exactly what gets in the way.
So SIDEQUEST has Chaos Mode.
Instead of carefully specifying the journey context, the user can simply give the available time and let the system create an unexpected adventure.
It's the same core idea with less planning:
You don't need a reason to explore.
You just need a little time.
Step 8: Local-first AI
The local version of SIDEQUEST runs:
React
β
FastAPI
β
Ollama
β
Gemma 3 4B
β
SQLite
Gemma 3 4B runs locally through Ollama.
That means the local application can generate quests on the same machine without depending on a remote AI API.
This was especially important for SIDEQUEST because the application deals with context about someone's movements, interests, and reflections.
In local mode, that information can stay on the machine.
Step 9: A public demo without pretending it's offline
I still wanted anyone to be able to try SIDEQUEST without installing Python, Ollama, or a local model.
So the public demo is deployed as:
React / Vite frontend
β
Render
β
FastAPI backend
β
Hosted AI inference
The hosted version is intentionally labeled as hosted.
The offline/on-device claim belongs to the local Ollama version, not the Render deployment.
That's an important distinction I wanted to keep honest.
π A Technical Lesson: Fallbacks Shouldn't Hide Bugs
One of the useful lessons from building SIDEQUEST was that a fallback can make a broken system look healthy.
When generation fails, SIDEQUEST can safely fall back rather than showing a raw error to the user.
That's good product behavior.
But during development, a silent fallback could make it look like the AI was working when it wasn't.
So I kept the user experience graceful while making sure backend failures remain visible during development and debugging.
The principle is simple:
Fail safely for the user.
Fail loudly for the developer.
π Another Lesson: Generated Text Is Still Input
SIDEQUEST feeds information from previous quests and user reflections back into later personalization and generation.
That means stored text should not automatically be treated as trusted instructions.
The generation pipeline separates structured application context from generated/user text and applies safety and validation before content becomes part of a new quest.
This matters because an AI system is not just vulnerable at the first prompt.
Its own previous outputs become future inputs.
π§ Why Open Innovation Matters
A closed API would have made SIDEQUEST a different product.
The open-weight/local approach gives me something important:
- The data can stay local In local mode, journey context, feedback and reflections can remain on the user's machine. That matters for a product dealing with personal routines and experiences.
- The AI can work without internet access With Gemma running through Ollama, the local version can continue generating quests even when the network is unavailable. That means the model can go where the user goes. A park. A train. A neighborhood walk. Somewhere with no signal.
- I can change the AI stack The AI isn't permanently tied to a single proprietary endpoint. The model can be replaced. The prompts can be inspected. The generation pipeline can be modified. The ranking layer can be changed independently of the model.
- The important behavior stays in code I can inspect The safety filter, validation, candidate ranking and personalization logic aren't hidden behind a black box. That makes experimentation much easier. And for SIDEQUEST, that matters because the interesting part isn't just the model. It's the system around the model.
β οΈ Honest Limitations
SIDEQUEST is still a prototype, and there are things I would improve with more time.
The local model can still be generic
A smaller local model can occasionally produce predictable or less creative quests.
Semantic repetition isn't perfect
Similarity checks reduce obvious repetition, but they cannot guarantee that two experiences will feel completely different.
Safety filtering is not a guarantee
The current safety layer uses explicit filtering and validation rules. It reduces risky outputs but cannot mathematically guarantee that every real-world activity is safe.
Anonymous personalization isn't authentication
The current public version uses anonymous browser-level identity rather than account-based login.
Different browsers can maintain separate histories, but logging into a different Google/Chrome account within the same browser does not create a different SIDEQUEST account.
The hosted demo is not offline
The public Render deployment requires network access.
The offline claim applies to the local Ollama setup.
This is not a user study
The project has been tested through development and personal usage, but I have not run a formal user study or controlled experiment.
I would rather state that clearly than manufacture a number that sounds impressive.
π οΈ Tech Stack
Layer Technology
Frontend React + Vite
Backend FastAPI
Database SQLite + SQLAlchemy
Local AI Ollama
Open-weight model Gemma 3 4B
Validation Pydantic
AI pipeline Candidate generation + filtering + ranking
Deployment Render
Version Control Git + GitHub
π The Bigger Idea
SIDEQUEST started from a very simple observation:
We don't necessarily need another app to tell us where to go.
We need better reasons to pay attention to where we already are.
The AI doesn't need to replace the world.
It just needs to make us notice it.
A good SIDEQUEST might take thirty seconds to read.
Then the screen disappears.
You walk.
You notice something.
You come back.
And the app has done its job.
My Agent Session
[Add your DevRelay agent session here]
π Prize Categories
Best Use of Gemma
SIDEQUEST uses Google's open-weight Gemma 3 4B as the core generative model for creating personalized real-world sidequests.
The local implementation runs Gemma through Ollama, allowing the AI generation layer to run directly on the user's machine.
Best Use of Render
SIDEQUEST uses Render to deploy the public frontend and FastAPI backend so the project can be accessed as a live web application.
π Links
Live Demo:
https://sidequest-jstk.onrender.com/
GitHub:
https://github.com/Bhavya4523/SIDEQUEST
Final Thought
Most AI products are trying to make you stay longer.
SIDEQUEST is trying to make you leave sooner.
The destination isn't the point.
The way there is.
#TouchGrassπ±






Top comments (1)
really fascinatingπ