This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
WHAT I BUILT
Trip-polama, is a colloquial term used in TamilNadu, a mix Tamil and English which means shall we go for a trip. From the header itself we can get to understand that this application can make people get off their seats and go offline for few days to explore the nature and experience the thrill.
DEMO
🚀 Live Demo: trip-polama.onrender.com
CODE
💻 GitHub Repository: karan-2004/trip-polama
🌟 What is trip-polama?
Most trip planning apps are great until you actually start your trip. The moment you hit a remote trail or a hill station with zero signal, your app becomes a glorified brick. Maps stop loading, expense tracking requires a server, and coordinating with your group becomes a game of "who has the last bit of LTE?"
trip-polama is an offline-first, "split-brain" trip manager designed specifically for hikers, trekkers, and outdoor groups. The goal is simple: get people off the screen and into the world, with open-source AI at the core.
🧠 The "Split-Brain" Architecture
I realized that the tools you need before a trip are fundamentally different from what you need during one. Instead of a monolithic app, I built two specialized "brains":
1. The Online Brain (The Planner)
When you have a connection, you need a powerhouse. The Online Brain uses larger open-weight models (like Gemma 4 or Llama 3) equipped with online research tools. It performs source-backed research using Wikipedia and other resources to suggest waypoints, check permits, and build a realistic itinerary.
Still need to work on the model to identify a better one which could infer budget and planning based on the current data available. It also needs to be fine tuned specifically for trip planning.
2. The Local Brain (The Manager)
Once you're offline, the brain shifts. The Local Brain is a lightweight system that lives entirely on your device. It handles the essentials with zero signal:
- Offline Waypoints: Mark your path and track visited stops.
- Expense Tracking: A local ledger to track spending and calculate "who owes whom" without a database.
- Photo Log: Capture memories locally without worrying about cloud uploads.
- Buddy Check-ins: Tracking last-known locations of group members.
- "Next Up" Suggestions: Context-aware tips based on your device location, weather, and pace.
It’s still not a working model in deployment where I need to figure out an even more smaller model to accommodate in mobile and needs more fine tuning in order provide accurate and quick responses offline.
🛠️ How I Built It
I chose a stack that prioritizes user control and offline reliability:
- PWA (Vite + React + TS): Built as a Progressive Web App so it installs on the home screen and works offline via service workers.
- Dexie.js & IndexedDB: All trip data, photos, and expenses are stored in the browser's IndexedDB. Your data stays on your device, not on a corporate server.
- MapLibre GL: Used for high-performance map rendering.
- Open-Weight AI: Integrated via an Ollama/Groq adapter, ensuring the AI is inspectable and swap-able.
- Node.js & Render: A lightweight gateway serves the frontend and manages the transition to larger online models.
🚧 Challenges I Faced
The biggest challenge was managing the "split" effectively. Ensuring that the chat history and trip context transitioned seamlessly between a massive online model (for planning) and a lightweight local logic (for managing) required a custom routing layer and a strict schema for AI actions.
Another hurdle was the PWA's background GPS behavior—modern mobile browsers are aggressive about killing background processes, which I had to account for in the "buddy tracking" design.
📚 What I Learned
This project taught me the power of local-first software. In an era of "everything-as-a-service," building something that intentionally doesn't need a server to be useful is a refreshing challenge. I also learned how to leverage open-weight models to create specialized roles (Planner vs. Manager) rather than relying on a single generic prompt.
🗺️ The Road Ahead
- On-Device Intelligence: Integrating WebLLM to bring the "Manager" brain fully on-device.
- Offline Maps: Implementing PMTiles for true offline map downloads.
- P2P Coordination: Using WebRTC for live buddy tracking without a central server.
- Privacy First: Automatic metadata stripping for photos.
🤖 AI Agent Session
Here is the transcript of the session where I deployed the app and drafted this post:
lets plan the archietecture and how to proceed forward
dont blindly urge to only submit a scrap
Curated milestone summary: We chose a no-rush PWA build with persistent trip conversations, local-first IndexedDB storage, manual trip tools, open-model integration, and versioned architecture plans. Supabase authentication/sync, on-device inference and peer-to-peer coordination were planned rather than represented as implemented.
lets have a plan copy within the repo with all versions of plan available, lets install specific skills within the repo to keep things smooth and lets maintain a memory bank to keep track of the project
Curated milestone summary: Added versioned plans, repository agent rules, AGENTS.md, a maintained README and a memory bank. Built an npm-workspaces foundation with a React/TypeScript/Vite PWA, deterministic geographic and expense logic, Dexie repositories, tests and CI.
lets go with the light theeme with natural skyblue, green colours to blend with nature
add it to any design rules so that I dont need to reiterate
Curated milestone summary: Implemented a light nature palette and persistent design rules. Added trip creation, expenses and settlement, waypoints, next-stop suggestions, and group check-ins. Replaced coordinate entry/display with device or map selection and human-readable location labels. Photos gained an image picker and actual getUserMedia camera capture, with previews and local Blob persistence.
lets remove the locations options in photos and add stripping location metadata from the photo to plan whhich we can implement later
Curated milestone summary: Removed photo geolocation requests, tags and location display. Existing image files were not rewritten. Embedded GPS/location-metadata stripping was explicitly added as deferred work; no claim was made that original uploads were already location-free.
In the home page along with the trips section lets mainly focus on to a chat session per trip which needs to be the heart of the application where the model acts as the manager if the trip is already created or a planner if the trip is newly being added or being explored. Let the chat handle all the actions of the application along with the manual application usage.
Curated milestone summary: Made chat the primary home workspace. Exploratory chats persist before creation and become manager conversations after confirmed trip creation. Chat and manual tools share local records. Model actions use strict runtime schemas, scoped transactions, confirmation/dismissal, audit statuses and duplicate-execution protection.
lets be clear that the planner needs to opt a big llm to access online resources and provide efficient planner and the local agents role is to manage the trip read/write all the data via chat and provide summary and quick responses.
Curated milestone summary: Implemented separate routes: a server-configured online planner with a bounded resource-tool loop, and a local Ollama manager. Existing conversations can explicitly switch to Research/Replan and back. Local failures never silently escalate to cloud inference. Online research uses Wikipedia, with optional Brave Search; credentials remain server-side.
now we can test the model
Curated testing summary: Live llama3.2:3b checks revealed malformed or unrelated action proposals, so response schemas and a one-action manager policy were tightened. The configured deepseek-v4.1-flash cloud model was denied with HTTP 402; after the user switched to gemma4:31b, live Wikipedia-backed research and gateway requests succeeded. Name-only creation also exposed incomplete action envelopes and fenced JSON. Added clarification examples, one bounded output correction and strict validation after removing only an outer JSON fence.
Before creation of trip lets suggest the spot in the destination and use that data to create waypoints for the trip.for any creation or updation confirmation dont use json structure rather just confirm the data. read only actions to local model should not ask any confirmations. lets test more on the local model on data retrieval including summary, quick responses and other actions. lets also add an icon to add photos via chat(multi select).
Curated milestone summary: Added sourced nearby-place suggestions and selectable stop reviews, with selected waypoints saved atomically during trip creation. Confirmation cards show readable values rather than JSON. Read-only tools execute without approval; known short commands use deterministic local reads, while natural retrieval requests select a compact read tool and facts come from complete saved records. Added multi-photo chat previews and local album/history linkage without sending images to models. Expanded live local tests found hallucinated retrieval answers and later intermittent 90-second timeouts; the final expanded live run was interrupted and must not be described as all-green. Deterministic reads were accurate and fast.
lets change the app name to trip-polama
from code base level to UI and every where
Curated milestone summary: Renamed UI, page title, PWA, workspace packages/imports, source symbols, prompts and documentation to trip-polama. Preserved legacy database/preference IDs for saved-data compatibility. Rebrand verification passed 93 regression tests, typecheck, lint and production build. Created and pushed the public repository https://github.com/karan-2004/trip-polama; master contains commit b8598b1. Actual environment credentials were excluded.
create a new branch deployment and add those changes and commit
Curated deployment summary: Created deployment from master and committed 9fdbc54, feat: prepare protected Render deployment. Added one Node production server for the built frontend/API, Render PORT binding on [REDACTED], /healthz, production startup, shared demo sign-in with expiring Secure/HttpOnly/SameSite cookies, request budgets, safe static serving, render.yaml and deployment instructions. Verified 105 regression tests, typecheck, lint and PWA build; actual production-start smoke checks passed with synthetic secrets and no paid inference. At this checkpoint, deployment was committed locally but not pushed or provisioned on Render.
submit_agent_session
Session preservation summary: This is a curated milestone record, not a complete verbatim transcript. Secrets, session cookies and private machine paths have been omitted. Remaining work includes actual Render deployment and browser/device verification, faster and consistently reliable local inference, Supabase identities/sync, WebLLM, peer-to-peer coordination, offline map downloads, photo metadata sanitization and measured test coverage. Shared demo access and in-memory request limits are not a full production account or durable spending-control system.
Check out the repo and join me in building the future of private, autonomous outdoor exploration!
Prize Categories
I have used render for deployment which made my work much easier to take my project to the world. I would like to enter in render category.
I have used Gemma model through illama for the online brain for trip planner. I would also like to enter in this category.
Top comments (1)
people please use polampolampolam. as password to access demo.