This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
Planning a pilgrimage usually means ten browser tabs, a group chat, and a map you can't read at the gate. I built Temple Heritage so the planning takes five minutes and the rest of the day is spent at the temple, not on your phone.
What I Built
Temple Heritage is a pilgrimage-planning app for people who want to actually go, not just scroll. You pick your preferences, and an AI planner builds a day-wise yatra (pilgrimage trip) with the stops ordered by an optimized route, so you spend less time traveling and more time there.
The screen is only the planning step. The output is a day-wise itinerary, a route map with a Google Maps handoff for navigation, festival countdowns, and nearby temples, all meant to be used on the road. Each temple has a voice-enabled Q&A assistant (English and Hindi), and a pilgrimage passport tracks the temples you've visited, which pushes you to go to the next one.
The planner runs on an open-weight model, OpenAI's gpt-oss-120b, so the AI core of the app is open and swappable.
It's for families, devotees, and heritage travelers who find trip planning a chore.
Demo
I Took It Outside
I tested it on a real trip to Mahakaleshwar Temple in Ujjain, one of the 12 Jyotirlingas. I entered Ujjain, 2 days, and a temple-focused trip.
Instead of treating Mahakaleshwar as one more stop on a tourist checklist, the planner built the itinerary around the rhythm of a pilgrimage, including the early-morning Bhasma Aarti and the nearby temples.
The interesting part was the constraint. Bhasma Aarti starts at 4:00 AM, so dropping it randomly into a day plan would make everything after it unrealistic. The plan it gave me actually worked as a day: an early start, then a slower pace after.
That turned into a useful lesson for me. A planner shouldn't just generate places, it needs to generate a day that makes sense. Right now my validation catches invented temples, duplicates, and missing days, but it doesn't check timings. A time-aware layer for rituals like this is the next thing I want to build.
That's the problem Temple Heritage is trying to solve: turning a list of temples into a practical yatra.
How I Built It
- Frontend/backend: Next.js + TypeScript + Supabase (auth, DB, migrations)
- AI planner: OpenAI's gpt-oss-120b (open-weight) served through Groq, with schema validation to catch invented or duplicate temples
- Temple Q&A: RAG chatbot with a custom TF-IDF retriever I wrote myself, so there are no embedding API calls and no vendor lock-in
- Routing: nearest-neighbour + 2-opt route optimization (my own implementation, 23 tests) and Leaflet maps on OpenStreetMap
- Recommendations: content-based, collaborative, and popularity signals combined
- Quality: Vitest suite (140+ tests), ESLint, and CI on GitHub Actions that also deploys DB migrations
Why Does Open Innovation Matter?
- Swappable models: the model is open-weight, though I currently run it on Groq's hosted service. It's a single constant in the code, so I can switch models or self-host later without rewriting the app.
- Free to run: OpenStreetMap/Leaflet for maps and a self-written TF-IDF retriever for RAG keep the core features free per user. A pilgrimage app shouldn't need a subscription.
- Transparent: the routing, retrieval, and recommendation logic is all readable code, not a black box.
- What a closed API wouldn't give me: full control over retrieval and routing, and no per-call costs for maps or embeddings.
Top comments (0)