This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
What I Built
Frolic is a playful outdoor side-quest app that helps people spend less time scrolling and more time noticing the world around them.
Users choose their mood, available time, and preferred level of chaos. Frolic then generates a small, safe outdoor activity such as:
- Finding a suspiciously interesting rock
- Discovering a cloud with a backstory
- Observing a miniature ecosystem
- Finding an unexpected color palette
- Giving a nearby tree an absurdly formal title
The goal is not to keep people inside an AI conversation. The goal is to give them one reason to put their phone down and step outside.
Frolic also supports:
- Individual quest progress
- XP, streaks, and achievement badges
- Photo and video evidence submissions
- Personal outdoor camp history
- Group camps with invite links and shareable group codes
- MongoDB-backed quest and group data
- A fallback quest deck when the AI service is unavailable
- No Login/Signup required(code/link based invite)
- Using in smartphone is recommended for better experience
Demo
Code
How I Built It
Frolic is a Node.js and Express application with a browser-based frontend.
The AI generation flow uses the Hugging Face Inference Router with the open-weight model:
Qwen/Qwen2.5-7B-Instruct
The server sends the user's selected mood, time limit, and difficulty to the model and requests a structured JSON response containing:
{
"emoji": "🍃",
"kicker": "THE ART OF NOTICING",
"title": "Become a tiny nature detective.",
"description": "A short outdoor activity...",
"xp": 50,
"difficulty": "Gentle",
"minutes": 10
}
MongoDB and Group Camps
MongoDB powers the social part of Frolic.
Group camps allow users to:
- Create a camp
- Choose a shared outdoor quest
- Add a meeting location
- Generate invite links
- Share a short camp code
- Track accepted and pending participants MongoDB collections include:
groupCamps
groupCampInvites
individualCamps
questSubmissions
Render Deployment
Frolic includes a render.yaml configuration with:
Build command: npm ci
Start command: npm start
Health check: /health
The Hugging Face token and MongoDB connection string are configured as deployment secrets rather than committed to the repository.
The application validates and limits the model response before displaying it.
The rest of the stack includes:
- Node.js and Express for the application server
- Hugging Face Inference Router for open-weight AI generation
- MongoDB Atlas for camps, invites, profiles, and quest submissions
- MongoDB GridFS for uploaded quest evidence
- Render for deployment
- Vanilla HTML, CSS, and JavaScript for the frontend
- Local storage for lightweight personal progress such as XP and badges
Why Does Open Innovation Matter?
Frolic is built around the idea that AI should help people leave the screen, not become another reason to stay on it.
Using an open-weight model makes the behavior more inspectable and replaceable. I can change the model, adjust the system prompt, add safety constraints, or run the same experience through a different compatible inference provider without redesigning the application.
Open innovation matters here because:
- The model can be swapped instead of locking the project to one provider.
- The prompt and safety rules are visible in the repository.
- The application can use a local fallback when inference is unavailable.
- The experience can evolve toward private or self-hosted inference.
Prize Categories
I am entering the following partner categories:
- Best Use of MongoDB Atlas
- Best Use of Render
- Best Use of GitHub Copilot
Top comments (6)
vivek, this is a brilliant execution of the "touch grass" concept. using vanilla html, css, and js paired with a lightweight node backend is exactly the kind of constraint-driven, zero-bloat architecture i champion.
the detail that stands out most is your implementation of a "fallback quest deck" when the ai service is unavailable. graceful degradation is a hallmark of senior system design, ensuring the core user goal (getting outside) isn't blocked by an api timeout or rate limit.
this perfectly aligns with the "off radar" philosophy i write about: building thoughtful, lightweight tools that solve real human problems without fragile dependencies.
quick question on the ai flow: when using the hugging face inference router with qwen2.5-7b, how do you ensure it consistently returns valid structured json without hallucinating or breaking the schema? do you rely on a specific prompting technique, or do you have a lightweight json-parsing fallback on the server?
fantastic, highly principled build. checking out the repo now! 🐯🌿
Thank you , Yes — Frolic uses both prompting and server-side validation, but it does not currently guarantee schema-constrained generation at the model level. The server asks Qwen to return only JSON like
The system prompt also constrains:
The request uses the Hugging Face OpenAI-compatible endpoint.
The server then extracts the assistant content and parses it.
The Fallback behavior only shows when Hugging Face request fails,Request times out, The model returns invalid JSON,The response has missing required fields and JSON parsing fails.
vivek, that's the exact pragmatic approach I love to see. relying on strict prompting + server-side parsing is usually the sweet spot for 7B models, rather than over-engineering with heavy structured-output libraries.
your fallback logic is bulletproof too. catching invalid json and missing fields before it hits the ui is exactly how you prevent a broken user experience.
thanks for sharing the exact implementation details! keep building awesome stuff. 🐯🌿
Insightful breakdown! The architectural considerations for deterministic outputs and cost control were spot on.
I like how you’ve used Qwen to generate quests based on mood and time. The fallback quest system is a nice touch too, so the app can still work when the AI service is down.
Official Platform Update
Security protocols have been updated for all developer accounts.