🌿 Trailnote — An AI Trail Companion That Tells You to Put Your Phone Away
My submission for the Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass.
Plan the walk. Make the note. Put the phone away.
What if an AI outdoor app wasn't designed to keep you using it?
That was the question behind Trailnote.
We keep building software that wants more of our attention. More scrolling, more notifications, more interaction, more time staring at a screen.
So I wanted to try the opposite.
I built an outdoor trail companion where AI helps you prepare for a walk, and then the product actively encourages you to stop using it.
What is Trailnote?
Trailnote is a local-first digital field notebook for walking and exploring outdoors.
You tell it where you want to go, how much time you have, what kind of trail you prefer, and what you want to notice. It combines that information with route, elevation and weather data and creates a small field guide for your walk.
You can search for a place such as Baner Hill, Pune, even if you're currently somewhere else, or simply use your current location.
The interesting part isn't the planning, though.
It's what happens after it.
Trailnote creates a Trail Card that you can save or print before leaving. Once you're outside, Walk Mode becomes deliberately minimal.
And the instruction is pretty straightforward:
PUT YOUR PHONE AWAY.
Go walk.
Look around.
Listen.
Notice the leaves.
Pay attention to things you normally walk past.
Then, when you come back, open Trailnote again and record what you actually experienced.
That becomes your field journal.
Why build it this way?
I didn't want to make another hiking chatbot.
There are already plenty of applications that can tell you where to go, what to eat, what to see, and what to do next.
I wanted Trailnote to feel closer to an old field notebook than a social or fitness application.
The digital part prepares the experience.
The physical world is where the experience actually happens.
So the basic flow became:
PLAN → PREPARE → SAVE → LEAVE → EXPLORE → RETURN → REFLECT
That idea ended up influencing almost every part of the application.
The AI is local
The core AI in Trailnote is Gemma 2 running locally through Ollama.
I specifically wanted the AI layer to be something I could run on my own machine rather than making the whole application dependent on a proprietary cloud AI API.
Gemma isn't responsible for things that don't need an AI model.
For example, I don't ask the model to guess the distance of a trail or invent the current temperature.
Those things come from deterministic systems.
Gemma is used where language and interpretation actually help: creating the naturalist-style trail briefing, generating things to look for during the walk, understanding the user's interests, and shaping field notes into more polished naturalist prose.
The application validates the generated output with Zod and has a deterministic fallback when local inference isn't available.
That separation was one of the more important architectural decisions I made while building this.
The map doesn't need Google
For Trailnote, I wanted the geographic layer to be open as well.
The location search and reverse geocoding use OpenStreetMap through Nominatim.
Walking routes are generated with OSRM, while Leaflet handles the interactive map.
Weather comes from Open-Meteo.
So when I search for something like:
Baner Hill, Pune
the application finds the location, gets its coordinates, generates a route around that location, retrieves the weather for those coordinates, and then passes the relevant information into the trail-generation pipeline.
The user's current GPS location and the location they actually want to walk are treated as two separate things.
That sounds small, but it makes the application much more useful.
A trail card instead of another screen
One of my favourite parts of Trailnote is the Trail Card.
The generated trail can be turned into a physical-looking field card containing the route, distance, elevation, weather, things to notice, what to bring, safety information, and space for handwritten notes.
It can be printed before the walk.
This is intentional.
I didn't want to solve the problem of excessive screen time by creating a better screen.
I wanted to give the user something they could take with them and then stop looking at the application.
And then you come back
After the walk, Trailnote becomes useful again.
You can record what you saw, heard and felt, add a favourite moment, write a reflection, and optionally attach a photograph.
Those entries stay local to the device.
There is no MongoDB database, Firebase backend or Supabase database behind the journal. The project uses local browser storage because, for a personal field notebook, I didn't see a reason to send someone's private observations to a server.
The original note is also kept separate from the optional AI-shaped version.
I wanted the AI to help with the writing without pretending that it was the person who actually went outside.
The technology behind it
Trailnote is built with Next.js 15, React 19, TypeScript and vanilla CSS.
The AI layer uses Gemma 2 + Ollama + Zod.
For the outdoor data layer, it uses OpenStreetMap/Nominatim, OSRM, Open-Meteo and Leaflet, with browser geolocation for the current-location option.
The application is local-first, uses browser storage for personal data, supports printable Trail Cards, and has a small PWA setup for mobile use.
The whole thing is currently deployed on Netlify.
Why open source AI made sense here
This project probably could have been built faster by calling a hosted AI API and moving on.
But using an open-weight model locally changed how I thought about the application.
The AI doesn't have to be permanently connected.
Personal field notes don't have to be uploaded just to get some writing assistance.
The model isn't locked into one proprietary API.
And the rest of the stack follows the same philosophy: open geographic data, open routing, open weather data and open-source libraries.
That's what I like about the open approach here.
It's not just that the model is open.
The whole application becomes more understandable, replaceable and local.
The part I'm most proud of
The most interesting thing I learned while building Trailnote is that AI doesn't always need to be the main character.
The obvious version of this project would have been:
"Chat with an AI about hiking."
But that's not particularly interesting to me.
The version I wanted was:
"Let AI prepare something useful, then go outside."
That distinction ended up becoming the product.
The application should disappear at exactly the moment the real experience begins.
Built for Touch Grass
The Hacktoberfest Week 1 challenge asks us to build something around the idea of Touch Grass.
Trailnote takes that literally.
Most applications optimise for engagement.
Trailnote optimises for getting you away from the application.
The screen is useful before the walk.
The world is the destination.
Plan the walk.
Make the note.
Put the phone away.
🌿
Try it
Live Demo:
https://trailnote.netlify.app/
Source Code:
https://github.com/AnshMeshram/TrailNote
The project is open source, and I'd genuinely love feedback on the idea, the UX, and especially the balance between AI assistance and getting people away from their screens.
If you try it, pick somewhere you've actually wanted to walk, make a plan, and then go outside.
That's the whole point.
🏆 Submission
Challenge: Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass
Category: Best Use of Gemma
Trailnote uses Gemma 2 through Ollama for local natural-language generation, including trail briefings, observation prompts and field-note shaping.
Top comments (0)