DEV Community: Arun Yadav

RecallLoop: I Built an AI That Turns Forgotten Bookmarks Into Lasting Knowledge

Arun Yadav — Sun, 25 Oct 2026 10:36:50 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

I have a habit that I suspect many developers share.

I discover an interesting article about system design, Python, databases, or something completely new. I think, "This looks useful. I'll read it properly later."

I bookmark it.

Then I find another article. And another.

A few weeks later, my bookmarks have become a collection of things I wanted to learn but barely remember.

The problem isn't that I can't save information. It's that saving information doesn't mean I've learned it.

For this week's Slow and Steady challenge, I wanted to build something that does the repetitive preparation work for me, while making it easier to build knowledge over time.

That's how RecallLoop started.

Save it. Learn it. Remember it.

What I Built

RecallLoop is an open-source, AI-powered learning companion that transforms saved articles into active-recall questions and schedules future reviews using spaced repetition.

Instead of manually rereading every article or creating flashcards from scratch, users can save a URL and let RecallLoop prepare the learning material.

Here's the experience:

1. Save an article

Paste a public article URL into RecallLoop. The application fetches the page and extracts its readable content, removing much of the surrounding website clutter.

2. Let AI find the important ideas

Google's open-weight Gemma 4 model analyzes the extracted text and generates up to three meaningful concepts, with explanations, questions, answers, and supporting excerpts from the original article.

3. Practice active recall

RecallLoop presents a question without immediately revealing the answer.

Try to remember it, reveal the answer, and assess how well you recalled the concept.

4. Choose how well you remembered

Each review has three options:

Forgot: Review again in approximately 10 minutes.
Hard: Review again sooner, initially after one day.
Easy: Start with a longer interval, initially three days.

Future intervals adapt to your review history using a deterministic scheduling algorithm.

5. Return when it's time to review

RecallLoop tracks due cards, upcoming review dates, and review history.

You don't have to repeatedly decide what to study next.

Who is it for?

I built RecallLoop for developers, students, self-learners, and anyone who saves useful articles but struggles to revisit them.

The idea is simple:

Let the machine prepare the questions. Let the learner do the remembering.

That distinction matters. RecallLoop doesn't eliminate learning effort. It eliminates some of the repetitive work surrounding learning.

Demo

Live application: https://recallloop-web.onrender.com/

Source code: https://github.com/itsdevcode/recallloop

RecallLoop interface

RecallLoop's landing page introduces a simpler way to turn saved knowledge into something useful.

The dashboard brings together saved articles, due reviews, and learning progress.

The review experience focuses on one question at a time, with the answer hidden until the learner is ready.

The demo is hosted using Render's free-tier infrastructure. Free services may sleep after inactivity, so the first request can take longer while the application wakes up.

The demonstration is intended for evaluation rather than uninterrupted production usage.

Code

The complete project is open source:

itsdevcode / recallloop

Turn saved articles into lasting knowledge with AI-powered recall and spaced repetition.

RecallLoop

Save it. Learn it. Remember it.

RecallLoop is an open-source learning companion that turns saved articles into recall cards and schedules focused reviews with a deterministic spaced-repetition policy Bookmarks preserve a link. RecallLoop gives its ideas a reason to return Save a public article, let hosted Gemma create source-grounded questions, and practice one card at a time. Your recall ratings determine when each card returns.

Implemented and planned

Implemented:

Independently runnable FastAPI API and Next.js frontend.
PostgreSQL users with database-generated UUIDs, normalized unique emails Argon2 password hashes, active status, and timezone-aware timestamps.
Registration, login, current profile, and logout endpoints.
Fifteen-minute HS256 JWTs transported only in an HttpOnly cookie.
Same-origin API proxies, CSRF protection, registration/login pages, and a protected dashboard.
Per-user article saving, paginated library, readable text details, and confirmed deletion.
Bounded, SSRF-protected public HTML fetching and Trafilatura extraction in Celery.
Hosted Gemma concepts and recall questions/answers with source evidence…

View on GitHub

RecallLoop uses a monorepo structure with separate frontend and backend applications.

recallloop/
├── recallloop-api/
│   ├── app/
│   │   ├── ai/
│   │   ├── api/
│   │   ├── core/
│   │   ├── models/
│   │   ├── services/
│   │   └── workers/
│   ├── alembic/
│   └── tests/
├── recallloop-web/
│   ├── src/
│   └── tests/
├── docs/
├── render.yaml
└── render.free.yaml

The repository contains the source code, database migrations, AI integration, review scheduling, deployment configurations, and tests.

How I Built It

RecallLoop combines an open-weight language model, background processing, a relational database, and a focused web interface.

Tech stack

Layer	Technology
Frontend	Next.js, React, TypeScript, Tailwind CSS
Backend	FastAPI, Python
Database	PostgreSQL
ORM and migrations	SQLAlchemy, Alembic
Background processing	Celery
Message broker	Redis-compatible Valkey
Article extraction	Trafilatura
AI model	Gemma 4 (`gemma-4-26b-a4b-it`)
AI integration	Google GenAI SDK
Hosting	Render
Testing	pytest, Playwright

1. Extracting useful content

A normal article webpage contains navigation, advertisements, menus, and other elements that aren't helpful when generating learning material.

RecallLoop uses Trafilatura to extract readable article text.

The fetching layer includes protections such as URL validation, public-network restrictions, redirect checks, and resource limits.

This was important because the application accepts URLs supplied by users.

2. Generating concepts with Gemma

The core AI component uses Google's open-weight Gemma 4 26B model through hosted inference.

I chose Gemma because I wanted an open-weight model to power the most important feature of the application: turning source material into useful learning questions.

The model is instructed to return structured information:

{
  "concepts": [
    {
      "title": "Database Indexes",
      "explanation": "A database index helps locate records efficiently.",
      "source_excerpt": "Exact supporting passage copied from the article",
      "question": "Why can an index improve database query performance?",
      "answer": "It provides an efficient lookup path instead of requiring every row to be examined."
    }
  ]
}

Illustrative structure; not a verbatim model response.

Each concept must satisfy validation rules.

For example:

Questions and answers must be meaningful.
Duplicate questions and concepts are rejected.
The supporting source excerpt must appear in the extracted article text.
Invalid responses can trigger a bounded repair attempt.

The model is not allowed to invent source evidence.

This makes RecallLoop more than a generic text-generation interface. The AI output has to be usable within a real learning workflow.

3. The unexpected JSON problem

One of the interesting technical challenges appeared during live Gemma testing.

My first smoke test failed with a generic AIError.

After adding safer diagnostics, I discovered that the model sometimes returned valid JSON wrapped in Markdown code fences.

For example:

{
  "concepts": []
}

The original parser expected raw JSON, so it rejected that response.

I added a JSON extraction step while keeping Pydantic validation and source-evidence verification.

Later testing also revealed occasional schema-validation failures. A subsequent real smoke test successfully generated and validated three concepts in approximately nine seconds.

That was a valuable lesson: a successful model response isn't automatically a valid application response.

When using AI inside software, output validation is part of the product, not an optional extra.

4. Background processing with Celery

Article processing involves multiple steps:

Save URL
   ↓
PostgreSQL: PENDING
   ↓
Celery worker
   ↓
Fetch and extract article
   ↓
Gemma generates learning material
   ↓
Validate concepts and evidence
   ↓
PostgreSQL: READY
   ↓
Recall session

I didn't want users to sit on a loading screen while extraction and AI generation happened inside an HTTP request.

FastAPI saves the article and queues processing. Celery handles extraction and generation in the background.

The implementation includes retry limits, processing leases, and recovery logic to handle interrupted jobs.

5. Spaced repetition without asking AI to schedule reviews

I deliberately kept scheduling separate from Gemma.

AI generates the concepts and questions.

A deterministic Python algorithm decides the next review time.

For example, a forgotten card comes back quickly, while an easily remembered card receives a longer interval.

The system persists review history, timestamps, repetition counts, and scheduling state in PostgreSQL.

This approach makes scheduling predictable, testable, and independent of model output.

It's a simplified learning policy, not a claim to implement FSRS or the full SM-2 algorithm.

6. Deploying on Render's free tier

RecallLoop has two Render configurations:

render.yaml for the original paid production architecture.
render.free.yaml for a lower-cost demonstration setup.

The free configuration runs:

Next.js frontend
FastAPI backend
PostgreSQL database
Valkey broker

Because dedicated background workers require paid compute, the free demonstration colocates FastAPI and Celery in one web service.

That introduces trade-offs: both processes share limited memory, the service can sleep, and the free database has a limited lifetime.

I chose to document those limitations rather than describe the demo architecture as production-ready.

Why Does Open Innovation Matter?

For RecallLoop, open innovation is about control over the technology that makes the product valuable.

Gemma's open-weight availability means that the learning-generation component is not conceptually tied to one proprietary model endpoint.

Today, my implementation uses hosted Gemma inference through Google's API. It does not run offline.

However, an open-weight model creates opportunities for future development:

Model portability: The inference layer can potentially be adapted to different compatible hosting environments.

Experimentation: Developers can study how prompt design, validation rules, and model selection affect generated learning material.

Customization: The system could eventually support models adapted for different subjects or learning styles.

Transparency: Developers can inspect how RecallLoop extracts articles, validates model responses, and schedules reviews.

A closed API could also generate flashcards. The advantage of the open-weight approach is the flexibility to explore alternatives without making the underlying model permanently dependent on one proprietary provider.

Open innovation makes experimentation and collaboration easier.

And because RecallLoop itself is open source, other developers can examine its architecture, improve the scheduling algorithm, or build new learning experiences around it.

The Lazy Payoff

The repetitive work I wanted to eliminate wasn't the act of studying.

It was everything around studying.

Before RecallLoop, turning an article into a review routine meant manually identifying concepts, writing questions, recording answers, and deciding when to revisit them.

With RecallLoop, that preparation is handled by the application.

Before RecallLoop	With RecallLoop
Manually identify important ideas	Gemma proposes source-grounded concepts
Write flashcard questions	Questions and answers are generated
Track review dates manually	Reviews are scheduled automatically
Search through old bookmarks	Due cards appear in one place
Decide what to revise next	A focused review queue guides the session

I haven't measured long-term retention improvements or time saved across real users yet.

But the core workflow already demonstrates the benefit: a saved article can become structured learning material without manually creating each flashcard.

The learner still has to think.

The application handles much of the preparation and organization.

That's the kind of laziness I wanted to reward.

What I Learned

This project taught me several practical lessons.

First, model output needs careful validation. Even when a model is available and responding, the output can violate a strict schema.

Second, background processing requires recovery planning. Fetching content and generating questions aren't always reliable operations.

Third, simpler algorithms can be useful. A transparent scheduling policy was easier to reason about and test than introducing unnecessary complexity.

Finally, deployment constraints shape architecture. Running a backend and worker on a limited free instance requires compromises that should be documented openly.

What's Next?

There are several directions I'd like to explore:

More sophisticated spaced repetition, potentially using FSRS.
Better article organization.
Importing existing bookmarks.
Improved question quality and personalization.
More flexible open-weight model hosting.
Better learning analytics.

For now, I wanted RecallLoop to solve one focused problem:

Help people remember more from the things they already save.

Prize Categories

I'm entering:

Best Use of Gemma

RecallLoop uses the open-weight Gemma 4 model as its central AI component. Gemma transforms extracted articles into source-grounded learning concepts, questions, and answers.

Best Use of Render

RecallLoop's live demonstration is deployed on Render using its web services, PostgreSQL, and Key Value infrastructure. I also built a free-tier deployment configuration that combines the API and Celery worker within a constrained demonstration environment.

If you've ever saved an article and never opened it again, I'd love to hear how you deal with that problem.

Try RecallLoop: https://recallloop-web.onrender.com/

Explore the code: https://github.com/itsdevcode/recallloop

Save it. Learn it. Remember it.

GiftMind: Turning Memories Into Meaningful Gifts

Arun Yadav — Sun, 18 Oct 2026 07:45:49 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

I Built GiftMind: An AI Side Hustle That Turns Memories Into Meaningful Gifts

What if the most meaningful gift isn't something you buy, but a memory you turn into something unforgettable?

We've all struggled to find the perfect gift.

You open an online store, search for "best birthday gifts," browse hundreds of products, and eventually pick something generic.

The problem isn't a lack of choices.

It's a lack of personalization.

That's why I built GiftMind — an AI-powered gifting platform that transforms someone's interests, personality, and shared memories into personalized gift ideas and story keepsakes.

Built with Google's open-weight Gemma 4 model and deployed on Render, GiftMind explores how AI could power a practical, affordable digital gifting side hustle.

What I Built

GiftMind combines two experiences: AI Gift Discovery and AI Story Keepsakes.

1. AI Gift Discovery

GiftMind begins by asking about the person receiving the gift.

Users create a recipient profile containing:

Their relationship with the recipient.
Interests, hobbies, and preferences.
Personal quirks and meaningful memories.
The occasion and available budget.

Instead of generating generic shopping recommendations, Gemma 4 uses this context to propose three personalized gift concepts.

Each recommendation includes a title, description, estimated budget, personalization reasoning, and a creative presentation idea.

For example, imagine a friend who loves photography, coffee, vintage aesthetics, and exploring Jaipur.

Rather than suggesting a generic perfume or gift card, GiftMind can propose a themed photography experience or a personalized memory collection connected to those interests.

The AI is not just answering, "What should I buy?"

It's answering, "Why would this particular person love this gift?"

2. AI Story Keepsakes

This is my favorite part of GiftMind.

Sometimes, the most valuable gift is a shared story.

GiftMind includes a guided memory interview that asks users about how they met someone, their favorite moments, important milestones, and what makes that person special.

Gemma 4 transforms those answers into a personalized story.

The user can then:

Read and review the AI-generated story.
Edit its title and content.
Save the revised keepsake.
Download a formatted PDF to share or print.

The experience follows a simple journey:

Share your memories → Generate a personal story → Edit it → Create a keepsake.

One of my most important engineering decisions was to ground stories in the memories actually provided by the user.

The goal is not to manufacture emotional experiences. It's to help people express real ones more beautifully.

Who Would Pay for GiftMind?

The Week 2 theme is Side Hustle, so I designed GiftMind around a business idea with a plausible paying audience.

Potential customers include:

Couples preparing anniversary surprises.
Friends creating memorable birthday gifts.
Families celebrating parents and grandparents.
People creating personalized graduation or farewell keepsakes.
Small gifting businesses offering customized digital products.

A potential business model could include free basic gift recommendations and paid premium keepsakes.

For example:

Product	Proposed Price
Basic gift discovery	Free
Personalized digital keepsake	₹99
Premium printable keepsake	₹249
Customized gift bundles	Future offering

These are proposed prices, not actual sales or launched payment plans.

The current MVP focuses on validating the experience before implementing payments.

For an independent developer, this type of product offers an interesting opportunity: a digital gift can be generated and delivered without holding physical inventory.

Of course, real profitability would depend on inference costs, hosting expenses, conversion rates, and customer demand.

Demo

GiftMind is deployed on Render.

Live Application: https://giftmind-web.onrender.com

Backend API: https://giftmind-api.onrender.com

API Health Endpoint: https://giftmind-api.onrender.com/health

Try the Experience

Open the GiftMind application.
Create an account or log in.
Add a recipient and describe their interests.
Create a gift project with an occasion and budget.
Generate three personalized gift ideas using Gemma 4.
Complete the memory interview.
Generate, edit, and export a story keepsake as a PDF.

The frontend and backend services are deployed successfully. The database migrations have also run on the production database.

Note: The complete browser journey should be tested before treating every interaction above as verified in production.

Screenshots

Code

The entire GiftMind project is available on GitHub:

GitHub — itsdevcode/giftmind

The repository includes the backend, frontend, AI integration, database migrations, and automated tests.

GiftMind was built as a full-stack application, not just a prompt wrapped in a simple interface.

How I Built It

Technology Stack

Layer	Technology
Open-weight AI	Google Gemma 4 26B A4B
AI SDK	Google Gen AI Python SDK
Backend	Python, FastAPI
Database	PostgreSQL 16
ORM	Async SQLAlchemy
Migrations	Alembic
Frontend	Next.js 15, React, TypeScript
Styling	Tailwind CSS
PDF generation	ReportLab
Infrastructure	Render
CI and testing	GitHub Actions, Pytest, Ruff

Building Around Gemma 4

GiftMind uses the instruction-tuned model:

gemma-4-26b-a4b-it

I chose Gemma because I wanted an open-weight AI model at the heart of the product rather than relying entirely on a closed-model ecosystem.

For this challenge, I used Google-hosted inference through the google-genai SDK.

That removed the immediate need to run GPU infrastructure, while keeping the application's AI layer designed around an open-weight model.

The model powers two core workflows:

Gift recommendations: It interprets recipient interests, relationships, occasions, and budgets to create thoughtful suggestions.

Memory-based storytelling: It transforms structured user-provided memories into a personal keepsake.

AI Architecture

The backend separates the AI provider from the application's business logic.

This allows different parts of the system to remain independently testable:

API routes handle validation and access control.
Services manage gift and story workflows.
The AI provider handles Gemma inference.
Structured response validation checks model output.
PostgreSQL stores the resulting data.
ReportLab creates the downloadable keepsake.

AI responses are validated before persistence instead of assuming every generated response is correctly formatted.

The application also handles provider errors and timeouts so failed generations don't have to corrupt saved project data.

Making AI Output More Reliable

A personalized gifting product needs stronger guarantees than a basic chatbot demo.

I implemented safeguards around:

Grounding: Story generation uses user-provided memories as its factual foundation and prompts discourage invented experiences.

Validation: AI-generated recommendations and stories must match expected application structures.

Ownership: Authentication and project-level authorization restrict access to each user's data.

Concurrency: PostgreSQL constraints help prevent conflicting active generation requests for the same project.

Editing: Users can review and modify generated keepsakes before exporting them.

The user remains the final editor of the personal story.

Automated Tests and Real AI Testing

At the completion of the keepsake implementation phase, GiftMind had 74 passing PostgreSQL-backed backend tests.

The test suite covers important application behavior, including authentication, ownership, generation workflows, persistence, and PDF export.

I also tested the hosted Gemma integration directly.

One real recommendation smoke test generated three validated personalized gift ideas in approximately 30 seconds.

This was a useful lesson: mocked AI responses are excellent for automated tests, but real provider behavior still needs separate verification.

Deploying GiftMind on Render

For the deployment, I created three separate Render resources:

1. Next.js Web Service

Hosts the public frontend and provides the user interface for gift discovery and keepsake creation.

2. FastAPI Web Service

Handles authentication, recipient profiles, projects, Gemma 4 integration, story generation, and PDF export.

3. PostgreSQL Database

Stores users, recipient profiles, gift projects, generated recommendations, memories, and saved keepsakes.

The application uses secure environment variables for database access, signing secrets, and the Google API key.

The frontend also uses a server-side API proxy to keep browser API calls on the same origin.

During the first deployment, I encountered an interesting production issue: the backend rejected an insecure JWT signing-secret placeholder.

Rather than bypassing the validation, I corrected the environment configuration with a secure random secret.

After redeployment, the PostgreSQL migrations completed, FastAPI started successfully, and Render marked both web services live.

It's a small detail, but one that matters: production safety checks should remain enabled, even during hackathons.

Why Does Open Innovation Matter?

For a side hustle, choosing the AI foundation is also a business decision.

A promising product needs room to evolve as its audience, infrastructure costs, and requirements change.

Open-weight AI offers meaningful flexibility.

Freedom Beyond One Hosted Endpoint

GiftMind currently uses hosted Gemma inference.

However, Gemma's available model weights create a path toward future self-hosted deployments or customized infrastructure, subject to the model's license.

That matters because a product shouldn't need to be redesigned every time its inference strategy changes.

More Opportunities for Specialization

Personal gifting is a specialized use case.

Future versions could experiment with evaluations and adaptation focused on culturally relevant gift ideas, grounded personal storytelling, and different gifting occasions.

An open-weight foundation makes it possible to explore techniques beyond prompt engineering alone.

Better Business Flexibility

A ₹99 digital product cannot support unlimited infrastructure costs.

As demand grows, having the ability to compare hosted model inference against self-hosting becomes valuable.

Open-weight models aren't free to operate: compute, storage, hosting, maintenance, and model evaluation still have costs.

But additional deployment choices help small developers explore sustainable economics.

An Open-Source Application Others Can Build On

GiftMind's application code is publicly available.

Developers can inspect the AI integration, contribute improvements, experiment with prompt strategies, or extend the gifting workflows.

I believe open innovation matters most when it helps more people build practical products, not just research prototypes.

A note about privacy: The current application uses Google-hosted inference, so relevant recipient information and memories are sent to that provider for processing. GiftMind is not an offline or fully local AI application.

What I Learned

Building GiftMind reinforced an important distinction:

Making an AI API call is easy. Building a usable AI product is harder.

The difficult work includes deciding what the user needs to provide, validating generated output, handling failures, saving progress, protecting user data, and making sure the final result is genuinely useful.

Another lesson was the importance of narrowing the scope.

I could have added shopping integrations, payment gateways, image generation, and dozens of gift templates.

Instead, I focused on two connected experiences: finding a thoughtful gift and turning personal memories into a keepsake.

For a side hustle, I believe proving that people value the core experience is more important than shipping every feature immediately.

What's Next?

My next milestone is real customer validation.

I want to test GiftMind with potential users, observe how they interact with the memory interview, learn whether they would actually gift the resulting PDF, and measure willingness to pay.

If the response is promising, the next features would be premium printable templates, additional personalization options, and a payment workflow.

For now, GiftMind is a deployed, open-source MVP exploring a simple idea:

Technology should help us make gifts more human, not less.

Prize Categories

Best Use of Gemma

GiftMind uses Google's open-weight Gemma 4 26B A4B as the core AI model for personalized gift discovery and memory-based story generation.

Gemma is central to the product's value rather than an optional add-on.

Best Use of Render

GiftMind runs its public Next.js frontend, FastAPI backend, and PostgreSQL database on Render.

Render provides the application's deployment infrastructure, public service endpoints, environment configuration, and managed database hosting.

It enabled me to take the project from a local prototype to a publicly hosted MVP without building an infrastructure platform from scratch.

GiftMind — Turn Memories Into Meaningful Gifts.

Sometimes the best gift isn't another product.

It's proof that you remember what matters.

What If Your City Was Hiding Secrets? I Built WAYBOUND to Find Them.

Arun Yadav — Sun, 11 Oct 2026 19:42:22 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

WAYBOUND is an AI-powered, location-based mystery adventure platform that transforms ordinary neighborhood walks into immersive, clue-driven expeditions through real public places.

Open the app. Share your location. Receive a mystery. Walk toward it.

The app uses your real GPS coordinates to discover genuinely nearby public landmarks via Google Places API, then hands that real-world data to an open-weight Google Gemma 2 AI to generate a unique narrative mission: a title, progressive riddle clues, and a hidden destination revealed only when you physically arrive.

Who is it for? Anyone who's walked the same routes for years and suspects their city is more interesting than their daily commute suggests. It's built for curious pedestrians, urban explorers, families looking for structured outdoor adventures, and anyone who thinks games shouldn't require a couch.

The one rule WAYBOUND never breaks: every place you walk to is real. If the real-world discovery pipeline fails, the app says so. It never quietly substitutes a fictional location.

▶ Play WAYBOUND · ⭐ Star on GitHub

Demo

👉 Live app: https://waybound-frontend.onrender.com/

The full flow in five steps:

Enable location — browser GPS or pick an exploration city
Choose your adventure — pick an archetype (Mystery Seeker, Nature Lover, Fitness Scout…), duration (15 / 30 / 60 min), and difficulty
Follow the map — a dark-themed Google Maps view shows mystery search zones, live GPS position, and walking routes to clue waypoints
Solve clues — tap ? markers to read unlocked narrative riddles; voice narration is available hands-free via ElevenLabs or browser TTS
Arrive & claim XP — server-side Haversine geofence verification confirms physical arrival; XP is awarded and persisted atomically

Code

itsdevcode / waybound

An open-source AI adventure companion that turns nearby places into personalized real-world quests, encouraging people to explore, walk, connect, and spend more time outdoors.

WAYBOUND

Turn Real Places Into Real Adventures.

An AI-powered real-world mystery adventure platform.

WAYBOUND transforms ordinary neighborhood walks and nearby public landmarks into immersive, game-like mystery expeditions. Powered by open-weights Gemma AI, Google Places discovery, live GPS geolocation, and walking route navigation, WAYBOUND encourages explorers to get outside, solve environmental clues, discover hidden secrets in their cities, and team up with friends.

🌟 Project Overview

WAYBOUND bridges the gap between outdoor fitness, real-world exploration, and tabletop role-playing games.

Unlike conventional navigation applications (such as Google Maps or Apple Maps) that simply give you the shortest route from Point A to Point B, WAYBOUND deliberately keeps your final destination a secret. Instead, it generates an unfolding mystery adventure around you:

🔍 Real Locations, Never Fake Content: Every quest is grounded in authentic, publicly accessible parks, historical monuments, public art installations, architectural landmarks, or viewpoints queried via Google Places API…

View on GitHub

The full stack:

Layer	Technology
Frontend	Next.js 16 · React 19 · TypeScript · Tailwind CSS
Backend	Python 3.12 · FastAPI · SQLAlchemy 2.0 (async) · PostgreSQL · Alembic
Location Discovery	Google Places API (New) — real public places only
Maps & Navigation	Google Maps JS SDK · Google Routes API (walking polylines + ETA)
AI Storytelling	Google Gemma 2 (open-weights, via Google AI API)
Voice Narration	ElevenLabs TTS · Browser Web Speech API fallback
Authentication	Passwordless email OTP (HMAC-SHA256, Resend / SMTP / Gmail)
Deployment	Render Blueprint (IaC, auto-migration, managed PostgreSQL)
Testing	Pytest (133 backend cases) · Vitest (74 frontend cases)

How I Built It

The Core Architecture Problem: AI Lies About Places

AI is brilliant at generating vivid, convincing place descriptions. It will happily invent an "ancient clock tower on Merchant Street" with the confidence of a local historian — even if that tower doesn't exist.

In a couch game, that's harmless. In an app that asks people to physically walk somewhere, it's a fundamental failure of trust.

The entire WAYBOUND architecture is designed around one constraint:

Google Places finds the real location. AI writes the story around it. Never the other way around.

Here's the validated pipeline every quest passes through before it reaches a player:

User GPS Coordinates
        │
        ▼
Google Places API ──► Candidate Real Places
        │
        ▼
Gemma 2 AI Layer ──► Mission Title + Clues + Proposed Waypoints
        │
        ▼
Backend Validation ──► semantically_matches_clue()? is_publicly_accessible()?
        │
        ▼
Quest Stored in PostgreSQL (only validated, real Place IDs)
        │
        ▼
Frontend: Progressive Reveal ──► Player walks, unlocks clues, arrives

The AI Storytelling Service

The GemmaQuestProvider receives:

The validated destination (a real place with a verified Google Place ID)
Up to two semantically matched intermediate waypoints
The explorer's approximate area and chosen archetype

From that, Gemma generates a mission narrative, escalating riddle clues, and an atmospheric story arc. The AI proposes waypoints by description; the backend runs two validation checks before any waypoint is ever stored:

# app/services/providers/gemma.py (simplified)
def is_publicly_accessible(candidate: PlaceCandidate) -> bool:
    """Rejects permanently/temporarily closed locations and inaccessible types."""
    if candidate.business_status in ("CLOSED_PERMANENTLY", "CLOSED_TEMPORARILY"):
        return False
    if candidate.primary_type in INACCESSIBLE_TYPES:
        return False
    return True

def semantically_matches_clue(clue: str, candidate: PlaceCandidate) -> bool:
    """
    Validates that a waypoint candidate semantically matches the clue text.
    Uses significant name tokens + a curated landmark synonym dictionary
    (e.g. 'fountain' → {'basin', 'water', 'cascade', 'pool', 'spout'}).
    """
    clue_lower = clue.lower()
    name_tokens = [t.lower() for t in re.findall(r"\b[A-Za-z0-9]{3,}\b", candidate.name)
                   if t.lower() not in STOP_WORDS]
    for token in name_tokens:
        if token in clue_lower:
            return True
        if any(syn in clue_lower for syn in LANDMARK_SYNONYMS.get(token, set())):
            return True
    return False

If validation fails, the waypoint slot stays empty and the adventure continues without it — no invented fallback, ever.

Real-World Reward Engineering

Arrival verification can't just be a client-side check — GPS coordinates are trivially spoofable. WAYBOUND runs Haversine distance calculation server-side before awarding any XP. Quest completions are stored atomically with duplicate-prevention logic, so repeated requests for the same quest yield no additional reward.

Cooperative Party Mode

In two-player fellowship mode, the system distributes complementary clue fragments between partners. One explorer sees Fragment I (the where); the other sees Fragment II (the why). To progress, they have to communicate — turning walking with someone into solving something together.

Google Places Integration

The GooglePlacesService queries the Places API (New) searchNearby endpoint with a curated set of public exploration types (parks, museums, monuments, historical landmarks, sculptures, botanical gardens) and a strict field mask that avoids expensive billing fields. Results are cached in-memory with a 5-minute TTL to minimize API cost during repeated session loads.

Why Does Open Innovation Matter?

WAYBOUND is built around Google Gemma 2, an open-weight large language model. That choice was deliberate, not incidental — and it shapes what the project can and can't do.

Open weights let the architecture be honest about failure modes.

A closed API that hides its model weights and training data makes it extremely difficult to audit why it invents a place, how to constrain it, or how the model would behave across different geographies and languages. With Gemma's open-weight nature, the entire pipeline — from prompt construction to output validation — can be inspected, forked, and improved in public.

More concretely, open innovation made the following possible:

Community-auditable anti-hallucination logic. The semantically_matches_clue() validator and the LANDMARK_SYNONYMS dictionary are open for anyone to extend. A contributor in Tokyo can add Japanese landmark synonym mappings. One in São Paulo can tune the validator for Portuguese place naming conventions. A closed model would make this sort of collaborative curation nearly impossible.
Deployable without vendor lock-in. Because the model weights are open, a self-hosted deployment (e.g., via Ollama or a local inference server) is entirely feasible. No single API provider can unilaterally break WAYBOUND's core functionality by changing pricing or access terms.
Trustworthy for outdoor navigation. People following WAYBOUND into unfamiliar areas need to trust the system. Open-source code means the full validation pipeline is auditable: the community can verify that no place is ever fabricated and that arrival verification happens server-side. That transparency is hard to achieve with a black-box platform.
Extensible by the community. The provider architecture (QuestProvider base class → GemmaQuestProvider implementation) is designed so contributors can swap in alternative open-weight models without touching the quest generation orchestration layer. WAYBOUND can evolve alongside the open-source AI ecosystem.

Open innovation didn't just make WAYBOUND possible — it made it trustworthy in the specific way that a real-world application demands.

Prize Categories

Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass
Google AI / Gemma track (open-weights AI: Google Gemma 2)
Google Maps Platform track (Google Places API, Google Routes API, Google Maps JS SDK)

Your city. Your story. Your adventure.

Have a city in mind? Drop it in the comments — I'd love to hear what mystery you'd want to solve there.

PlanB: An AI That Challenges Your Plan Before Reality Does

Arun Yadav — Sun, 04 Oct 2026 17:20:52 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I have a friend who is good at making plans.

But there is one problem: his plans usually depend on everything going right.

The train arrives on time.

The internet works.

There is enough time.

Nothing unexpected happens.

And that made me think:

What if AI didn't make Plan A for you, but instead helped you prepare for what could go wrong?

So I built PlanB.

PlanB is an AI-powered backup plan assistant built with Gemma.

You give PlanB the plan you already have. Instead of replacing it, PlanB looks at what your plan depends on and finds realistic things that could go wrong.

For every risk, it gives you:

Impact
Warning signs
Prevention
A backup action

It also creates a Prepare Now checklist, so you can take action before something goes wrong.

But I wanted PlanB to handle something else too:

What happens when the problem has already happened?

That's where Plan C comes in.

Tell PlanB what actually went wrong, and it uses your original plan, its earlier analysis, and the new situation to help you decide what to do next.

The complete flow is:

Plan A → Find what could go wrong → Plan B → Something actually goes wrong → Plan C

Demo

Let's take a real example.

Plan A

Tomorrow I have a job interview in Delhi at 11 AM. My train leaves at 6 AM and I expect to reach Delhi by 9 AM.

PlanB first understands the goal.

Then it identifies things this plan depends on, such as:

the train arriving with enough time before the interview
reaching the station on time
local transport being available in Delhi

It then generates realistic risks, warning signs, prevention steps, and backup actions.

But then reality changes...

Suppose I tell PlanB:

My train is running two hours late.

PlanB doesn't start from zero.

It already knows my original goal and the risks around it.

It uses that context to create Plan C, including:

Immediate actions
A revised plan
Additional risks to watch for

🌐 Live Demo

https://planb-five-pink.vercel.app

🎥 Video Demo

https://youtu.be/xklFTVIHJAw

Code

PlanB is completely open source.

GitHub

https://github.com/itsdevcode/planb

I deliberately kept the architecture small and focused:

Next.js Frontend
       ↓
FastAPI API
       ↓
PlannerService
       ↓
Gemma
       ↓
Pydantic Validation
       ↓
Structured Plan B / Plan C

There is no authentication, database, background queue, or unnecessary infrastructure in this MVP.

For a weekend challenge, I wanted every part of the application to support the main idea.

How I Built It

Gemma is the core of PlanB

Gemma isn't an extra chatbot added to the application.

It powers the main reasoning behind both Plan B and Plan C.

For Plan B, the backend asks Gemma to analyze the user's existing plan and return structured information.

The response looks like this:

{
  "summary": "...",
  "assumptions": ["..."],
  "risks": [
    {
      "risk": "...",
      "impact": "high",
      "warning_signs": ["..."],
      "prevention": "...",
      "backup": "..."
    }
  ],
  "prepare_now": ["..."]
}

One important decision I made while designing the prompt was to focus on realistic problems instead of extreme ones.

For example, I don't want PlanB to say:

Your train could crash.

I want it to say:

Your train could be delayed enough that you miss the interview.

PlanB should help people prepare, not make them afraid.

Building Plan C

Plan C gives Gemma three important pieces of context:

The original Plan A
The Plan B analysis
What actually went wrong

Gemma then generates:

Immediate actions
A revised plan
Additional risks

This means Plan C isn't just a new unrelated AI response. It continues from the context PlanB already understands.

Structured AI Output with Pydantic

I didn't want the frontend to depend on unpredictable AI text.

The FastAPI backend validates Gemma's output using Pydantic models.

For example:

class Risk(BaseModel):
    risk: str
    impact: Literal["low", "medium", "high"]
    warning_signs: list[str]
    prevention: str
    backup: str

If the model response doesn't match the expected structure, the application doesn't blindly treat it as valid data.

This gives the AI layer a clear contract with the rest of the application.

Backend

The backend is built with FastAPI.

There are two main endpoints:

POST /api/v1/plans/analyze
POST /api/v1/plans/recover

/analyze takes Plan A and creates the Plan B analysis.

/recover takes the original context plus what went wrong and creates Plan C.

The backend is deployed on Render.

Frontend

The frontend is built with Next.js.

I kept the user flow intentionally simple:

Describe Plan A
      ↓
Analyze Plan
      ↓
Understand the Goal
      ↓
Find Assumptions
      ↓
Find Possible Problems
      ↓
Prepare Now
      ↓
Something Went Wrong
      ↓
Build Plan C

The frontend is deployed on Vercel.

Testing

I also added automated tests for the main API behavior.

Gemma calls are mocked in the test suite, so tests can verify the application contract without making real AI requests.

The MVP tests cover:

Health endpoint
Successful Plan B analysis
Invalid Plan A validation
Successful Plan C recovery
Invalid recovery input

Current result:

5 passed

One Bug Taught Me an Important Lesson

During development, Gemma sometimes returned an incomplete response.

At first, it looked like the AI or JSON validation was broken.

The real problem was much simpler.

I had configured an output token limit that was too small for the structured response I was asking Gemma to generate.

Removing that unnecessary restriction fixed the problem.

It reminded me that building an AI application isn't just about writing a prompt.

The model, generation settings, validation, backend, and frontend all have to work together.

I also learned that AI responses can take longer than normal API requests.

Instead of pretending the response is instant, PlanB shows a clear loading state while the plan is being analyzed.

Why Does Open Innovation Matter?

PlanB uses Gemma, an open-weight model, as its reasoning engine.

That matters to me because the intelligence behind the product doesn't have to be permanently tied to one closed model.

The application has a simple boundary:

Plan
  ↓
AI Reasoning
  ↓
Structured Schema
  ↓
Application

Today, I use Gemma through an API because it allowed me to build and ship the idea quickly during the weekend challenge.

But because Gemma is open-weight, there is a path to running the model through different infrastructure or even locally with suitable hardware in the future.

That is especially interesting for PlanB.

People might use it for plans involving:

Job interviews
Travel
Work
Personal events
Projects
Family plans

Some of those plans can contain private information.

Having an open-weight model creates more options for where that reasoning can happen.

For me, that's one of the most exciting parts of open innovation:

It gives developers more control over how intelligence becomes part of their applications.

Prize Categories

Best Use of Gemma

Gemma is the core reasoning engine behind PlanB.

It analyzes Plan A, identifies what the plan depends on, finds realistic failure scenarios, creates preparation steps, and generates Plan C when something actually goes wrong.

Best Use of Render

PlanB's FastAPI backend is deployed on Render.

The Render service handles the API layer connecting the Next.js frontend with Gemma and serves both the Plan B analysis and Plan C recovery workflows.

Final Thought

I started this project with a simple observation about a friend.

He didn't need another tool to make plans.

He needed something that could challenge the plan he already had.

That became PlanB.

And after building it, I realized the idea applies to much more than one person.

PlanB doesn't try to predict the future.

It simply helps you stay ready when things don't go as planned.

Because when Plan A fails, you should always have a Plan B.

Mastering Routing in FastAPI: From Flat Files to Clean Architecture

Arun Yadav — Wed, 09 Sep 2026 17:37:32 +0000

When building an API with FastAPI, it’s deceptively easy to dump every endpoint into main.py. A few @app.get() decorators here, a couple of @app.post() decorators there, and everything works.

Then your project grows. Suddenly, main.py is an 800-line monolith, team members are constantly hitting Git merge conflicts, and nobody knows where the user authentication logic ends and the billing logic begins.

FastAPI solves this with APIRouter. Here is how to structure your routing cleanly from day one.

1. The Core Tool: `APIRouter`

Think of APIRouter as a mini FastAPI app that doesn’t run on its own. It groups related path operations together, which you then mount onto your main application.

A typical modular directory structure looks like this:

my_project/
├── app/
│   ├── routers/
│   │   ├── users.py
│   │   └── items.py
│   ├── dependencies.py
│   └── main.py
└── requirements.txt

In your module (app/routers/users.py), define your router:

from fastapi import APIRouter, HTTPException

router = APIRouter()

@router.get("/")
async def list_users():
    return [{"id": 1, "username": "alice"}]

@router.get("/{user_id}")
async def get_user(user_id: int):
    return {"id": user_id, "username": "alice"}

Then, register it in app/main.py:

from fastapi import FastAPI
from app.routers import users

app = FastAPI()

app.include_router(users.router, prefix="/users", tags=["Users"])

Two key parameters to notice:

prefix: Prepend /users to every endpoint in the router. Notice how users.py uses / and /{user_id} instead of repeating /users everywhere.
tags: Groups these endpoints together in FastAPI's auto-generated Swagger UI (/docs).

2. Cleaner Endpoints with Shared Dependencies

One of the biggest advantages of APIRouter is attaching security checks or common dependencies to an entire group of routes at once.

Instead of writing Depends(verify_token) on 15 separate endpoints, apply it to the router level:

# app/routers/admin.py
from fastapi import APIRouter, Depends
from app.dependencies import require_admin_role

# Every route attached to this router will now require admin access
router = APIRouter(
    prefix="/admin",
    tags=["Admin"],
    dependencies=[Depends(require_admin_role)]
)

@router.delete("/purge-cache")
async def purge_cache():
    return {"status": "cache cleared"}

3. Nesting Routers for Sub-Resources

Real-world APIs often have hierarchical relationships—such as comments belonging to a specific post (/posts/{post_id}/comments).

Rather than hardcoding long prefix strings, routers can be nested inside other routers:

# app/routers/comments.py
from fastapi import APIRouter

comments_router = APIRouter()

@comments_router.get("/")
async def get_comments(post_id: int):
    return {"post_id": post_id, "comments": []}

# app/routers/posts.py
from fastapi import APIRouter
from app.routers.comments import comments_router

posts_router = APIRouter(prefix="/posts", tags=["Posts"])

# Mount comments directly under a specific post
posts_router.include_router(
    comments_router,
    prefix="/{post_id}/comments",
    tags=["Comments"]
)

Now, mounting posts_router inside your main.py automatically exposes both /posts and /posts/{post_id}/comments cleanly.

4. API Versioning Without Headaches

Versioning is simple when your routing is modular. You can bundle whole sets of routers under a version prefix:

# app/main.py
from fastapi import FastAPI, APIRouter
from app.routers import users, items

app = FastAPI()

# Create a v1 router
api_v1 = APIRouter(prefix="/api/v1")
api_v1.include_router(users.router, prefix="/users", tags=["Users"])
api_v1.include_router(items.router, prefix="/items", tags=["Items"])

# Include the full v1 bundle into the main app
app.include_router(api_v1)

When it's time for v2, you can spin up an api_v2 router alongside it without touching older client integrations.