Boutgo(Outside Bingo) 🌿 — Less Scrolling, More Strolling

A developer built Outside Bingo, an AI-powered outdoor adventure generator that turns a walk into a scavenger hunt by producing a personalized bingo card of five missions based on location, time, activity, and energy level. The Flask app uses SerpApi for destination discovery and Backboard for open-weight LLM quest generation with per-browser assistant memory, and ships with a credential-free demo mode, sixteen passing mocked tests, and instructions for local deployment on an Arduino UNO Q. Live SerpApi and Backboard integrations, the default meta-llama/llama-3.3-70b-instruct model, and the UNO Q deployment remain unverified.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass https://dev.to/challenges/hacktoberfest-week1-2026-10-05 What if your phone gave you a reason to put it down? I built Outside Bingo , an AI-powered outdoor adventure generator that turns an ordinary walk into a small scavenger hunt. Instead of endlessly scrolling through recommendations, you get five simple missions and a reason to explore the world around you. Outside Bingo helps people turn “I should go outside” into an achievable adventure. Choose your location, available time, preferred activity, and energy level. The application is designed to find real outdoor destinations and generate a personalized bingo card with five missions. Your card might ask you to find an unusual leaf, notice three different shades of green, listen for a bird call, or spend a minute quietly observing your surroundings. Complete missions to earn XP, track your progress, and build a history of your adventures. The app is designed to use assistant memory to adapt future quests to your preferences and reduce repetition. The philosophy is simple: generate your adventure, put your phone away, and go explore. Live application on Render: https://outside-bingo.onrender.com/ https://outside-bingo.onrender.com/ Demo video: https://youtu.be/ROBoa3Km5mk https://youtu.be/ROBoa3Km5mk The application includes a demo mode that lets people explore its main interface and bingo-card interactions without external API credentials. The live SerpApi and Backboard integrations still need verification with real credentials. The demo-mode experience should not be confused with live AI-generated results. GitHub repository: https://github.com/im45145v/Boutgo---Outside-Bingo https://github.com/im45145v/Boutgo---Outside-Bingo The repository contains the application, setup instructions, environment-variable template, automated tests, and deployment instructions. I used GitHub Copilot to help build the application, with a lightweight architecture intended to be easy to understand, modify, and deploy. The application uses Python, Flask, HTML, CSS, vanilla JavaScript, and SQLite. Its architecture separates the user interface, destination discovery, AI quest generation, and local progress storage. SerpApi powers the destination-discovery component. The application uses Google Maps search results to identify outdoor destinations and pass their available details to the quest-generation process. The intent is to make the missions grounded in actual places rather than generic suggestions or fictional destinations. The integration is implemented, but live API behavior has not yet been verified with credentials. Backboard is intended to provide access to an open-weight language model that generates five structured outdoor missions. The application also implements per-browser assistant identity, memory operations, and quest-history context. Together, these features are designed to make future missions more personal and avoid repeatedly suggesting the same activities. The configured default model is meta-llama/llama-3.3-70b-instruct through the openrouter provider. Its availability and successful execution through my Backboard account are not yet verified. GitHub Copilot helped me implement the application, while Render is the intended public hosting platform for the Flask web app. The project also includes instructions for running the same lightweight application locally on an Arduino UNO Q. This provides a path towards a locally hosted version, rather than making the public web deployment the only way to run the software. The UNO Q deployment itself has not yet been verified. Sixteen automated tests currently pass, with external network calls mocked. I also started the server and verified that the /health endpoint and a demo-mode adventure request respond correctly. The application includes response validation, XP bounds, SQLite persistence, timeouts, and clearly labelled fallback behavior when external services fail. Browser-based visual testing, live partner API calls, persistent memory personalization, and Arduino UNO Q deployment remain to be verified. I wanted the AI component to be something developers can experiment with and change, rather than building the entire experience around an inseparable closed-model API. An open-weight model makes model selection a configurable part of the application. The prompts, quest-generation flow, validation rules, and user experience remain under the project's control. The memory layer is designed to let future adventures adapt to users instead of treating every visit as a completely new interaction. The combination also creates room for future experimentation: compare open-weight models for mission quality, variety, latency, and cost, or explore whether parts of the experience can run locally. These are opportunities rather than measured results; I have not yet benchmarked models against a closed alternative. The current design uses online services for destination discovery and planned AI generation, so it is not an offline AI application. Its open approach is about adaptability, inspectability, and keeping the application extensible. Most importantly, AI should be the means to an outdoor adventure, not another reason to stay glued to a screen.