# 🌿 WildQuest AI: Less Scrolling, More Discovering

My submission for the Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass.

Most AI applications are designed to keep us on our screens: generating content, answering questions, and automating digital tasks.

I wanted to explore a different use of AI.

What if AI could help people spend less time interacting with technology and more time experiencing the real world?

That question led me to build WildQuest AI, a privacy-first nature exploration companion that turns outdoor activities into personalized quests and helps users document what they discover.

The idea isn't to make nature more complicated with technology. It's to use technology to make getting outside a little easier.

🌱 What Is WildQuest AI?

WildQuest AI is a full-stack application that combines locally running AI with a nature journal and outdoor activity tracking.

Users can generate personalized nature quests, complete them outdoors, record observations, and revisit their experiences later.

Instead of requiring a hosted AI service, the application can use a local model through Ollama. When the model is unavailable, a deterministic quest catalog provides a fallback.

Key features

• Personalized nature quests: Generate outdoor activities based on user preferences and available time.
• Nature journal: Save observations, experiences, and reflections.
• Session tracking: Keep track of outdoor exploration sessions and completed quests.
• Journal history: Search, revisit, and export saved entries.
• Achievements: Recognize exploration milestones without relying on manipulative engagement streaks.
• Local-first architecture: Store journal data in SQLite and support local AI inference.
• Graceful fallback: Continue generating quests through a deterministic catalog when local AI is unavailable.

🔗 Source Code

GitHub: https://github.com/Harsh63870/WildQuest-AI

🧠 Architecture: How It Works

I built WildQuest AI using a React frontend, a FastAPI backend, a local AI inference layer, and SQLite for persistence.

The frontend handles the user experience, while the backend manages quest generation and journal operations. The AI integration is optional at runtime because the application can fall back to predefined quest data.

System architecture

flowchart TD
    A["User"] --> B["React 19 + TypeScript"]
    B --> C["FastAPI Backend"]

    C --> D{"Local AI Available?"}

    D -->|Yes| E["Ollama"]
    E --> F["Qwen 2.5 3B"]
    F --> G["Generated Nature Quest"]

    D -->|No| H["Deterministic Quest Catalog"]
    H --> G

    G --> I["Quest Displayed in UI"]
    I --> J["Outdoor Exploration"]
    J --> K["User Records Observations"]
    K --> C

    C --> L[("SQLite Database")]
    L --> M["Journal History, Search and Export"]
    M --> B

The key design decision is that the AI model is not a hard dependency for the entire experience. If local inference is unavailable, the application can still provide quests through its fallback mechanism.

This makes the application more resilient and avoids making access to an AI model a prerequisite for going outdoors.

🛠️ Technology Stack

Layer	Technologies	Purpose
Frontend	React 19, TypeScript, Vite	User interface and application interactions
Styling	Tailwind CSS, Lucide	Layout, styling, and icons
Backend	Python, FastAPI, Pydantic	API endpoints, validation, and application logic
AI inference	Ollama, Qwen 2.5 3B	Local quest generation
Persistence	SQLite	Local storage for journal data
HTTP client	HTTPX	Backend HTTP requests
Testing	Python test suite, frontend build and type-check	Validate backend behavior and frontend compilation

🔄 Quest Generation and Data Flow

A typical interaction follows this sequence:

1. The user requests a nature quest.
2. The frontend sends the relevant preferences to the FastAPI backend.
3. The backend attempts to use the configured local AI model.
4. If inference succeeds, the generated quest is returned.
5. If the model is unavailable, the backend uses the deterministic fallback catalog.
6. The user explores outdoors and records an observation.
7. The backend saves the journal entry to SQLite.
8. The user can revisit, search, or export saved entries.

sequenceDiagram
    actor User
    participant UI as React Frontend
    participant API as FastAPI Backend
    participant AI as Ollama
    participant DB as SQLite

    User->>UI: Request a nature quest
    UI->>API: Submit quest preferences
    API->>AI: Request local inference

    alt Model available
        AI-->>API: Generated quest
    else Model unavailable
        API->>API: Select fallback quest
    end

    API-->>UI: Return quest
    UI-->>User: Display quest

    User->>UI: Save an observation
    UI->>API: Submit journal entry
    API->>DB: Persist entry
    DB-->>API: Confirm saved data
    API-->>UI: Return result

🔐 Why Local-First AI?

Privacy was an architectural consideration, not just a feature to mention in the README.

Using a locally running model means quest generation does not inherently require sending prompts to a hosted AI provider. SQLite also provides local persistence for journal data.

The design aims to provide:

• Local inference: Use Ollama rather than requiring a cloud AI API.
• Local persistence: Store journal entries in SQLite.
• No mandatory GPS tracking: Outdoor exploration does not require continuous location tracking.
• No mandatory account: The core experience does not depend on user registration.
• A fallback path: The application can still provide quests when local inference is unavailable.

These choices reduce external dependencies and give users more control over their data. They do not, by themselves, guarantee that every possible deployment or network request is completely offline, so the actual behavior depends on how the application is configured and run.

🧪 Testing and Validation

During local development, the backend test suite completed with 14 passing tests. The frontend build and type-check also completed successfully in my local validation.

These checks gave me confidence in the application before preparing it for submission. They are a useful baseline, though they do not replace broader integration, security, or real-world usability testing.

💡 Engineering Decisions and Trade-offs

A few decisions shaped this project.

1. Local inference instead of a mandatory hosted model

Running a model locally reduces dependence on external AI services, but it also introduces setup requirements and hardware constraints. A smaller model such as Qwen 2.5 3B is a practical starting point for experimentation on consumer hardware.

2. Deterministic fallback instead of total failure

AI services can be unavailable, slow, or misconfigured. A fallback quest catalog allows the core quest-generation experience to continue without successful model inference.

3. SQLite instead of a separate database service

The application is designed for an individual user's exploration and journal. SQLite keeps persistence simple and avoids requiring users to operate an additional database server.

4. AI as an assistant, not an authority

WildQuest AI focuses on suggesting activities and recording personal observations. It does not claim that generated content is a scientifically verified species identification system.

These trade-offs keep the initial implementation relatively lightweight while leaving room for future improvements.

🚀 What's Next?

There is room to take the project further:

• Expand quest categories and difficulty levels.
• Improve personalization using previous quests and user preferences.
• Add optional, carefully sourced nature observation guides.
• Improve accessibility and mobile usability.
• Expand automated tests and integration coverage.
• Improve setup documentation and troubleshooting.
• Evaluate optional integrations without making cloud services mandatory.

Any future species-identification feature would need reliable references, uncertainty handling, and validation rather than presenting AI-generated guesses as established facts.

🌍 Final Thoughts

WildQuest AI began with a simple idea: AI doesn't always need to help us do more things on a screen.

Sometimes, it can help us find a reason to put the screen away.

Building this project gave me an opportunity to explore local AI inference, backend API design, persistent storage, graceful fallbacks, and privacy-conscious product decisions in one application.

The technology supports the experience. The real objective is what happens after the user closes the app.

Less scrolling. More discovering. 🌿

---

Tags: #devchallenge #hf26challenge #opensource #ai #python #react