This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
What I Built
It’s easy to say “we should hang out sometime” and never make a plan. TouchGrass helps turn that idea into a real group outing: find a place, choose a mood and budget, check availability, and put together an itinerary with optional mini-quests.
It’s for friends and groups who want to spend more time together offline without making the planning itself a project. The app uses real place results from OpenStreetMap and can include a forecast when one is available. It also treats disconnected calendar availability as unknown, not as proof that someone is free.
Code
TouchGrass
Less scrolling. More living. A cross-platform social adventure planner for turning “we should hang out sometime” into a real plan.
TouchGrass is an Expo + TypeScript app with a FastAPI service, a local SQLite demo mode, optional Supabase-backed persistence, Google and native device-calendar availability, friend/group invitations, push notifications, and private quest-photo storage. OpenStreetMap place discovery, optional Ollama itinerary generation, and forecast-aware planning round out the hangout flow.
Integration status: these provider flows are implemented but require your own Supabase project, Google OAuth credentials (for Google Calendar), EAS/APNs/FCM configuration (for push), and an iOS/Android development build (for native calendar access). They have not been validated against your provider accounts or a production deployment. The backend uses its Supabase service-role key, which bypasses RLS; keep it server-only and complete deployment hardening and multi-user authorization testing before using real users or private data.
The current Expo/Metro dependency tree still reports upstream moderate/high…
How I Built It
The app is built with Expo and TypeScript, with a FastAPI backend and local SQLite demo mode. Supabase-backed persistence is optional.
The itinerary generator has an optional integration with Qwen3 8B via Ollama, an open-weight model that can run locally. The backend first verifies the destination, then sends the model only the place name, address and category, along with non-sensitive preferences such as mood, budget and outing length. The model returns a constrained JSON draft that the app validates before it can be used.
A note on the current demo: Ollama is optional and wasn’t configured for the local run, so the app uses a clearly labeled deterministic fallback instead of presenting it as AI-generated. The model integration is implemented, but still needs to be tried with a configured Ollama instance.
Why Does Open Innovation Matter?
For a planning tool, people’s calendars and preferences can be personal. An open-weight model gives developers the option to run inference locally or on infrastructure they control, rather than making a closed AI API the only path. It also makes the model choice replaceable as the project evolves.
Just as importantly, the app remains useful without a model. Open innovation here means being able to inspect and adapt the AI path, while keeping a predictable fallback for people who don’t have the model—or the hardware—to run it.
Prize Categories
Best Use of GitHub Copilot — I used Copilot CLI while getting the Expo app running, including troubleshooting and fixing the missing react-native-web dependency that blocked the web build
Top comments (0)