I built a trip planner so my friend group finally stops saying "let's go somewhere this long weekend"

Prince Singh — Sun, 04 Oct 2026 19:40:00 +0000

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

What I Built

Every long weekend, our group chat goes the same way. Someone says "let's go somewhere this time." Five people reply with a thumbs up. Nobody books anything. The weekend passes.

The problem was never a lack of places to go. It was that someone has to take the lead, and nobody wants to be that person every time.

So I built Trip Buddy: a small tool that notices a long weekend coming up three weeks ahead, plans three different trips for my group of six friends, and emails each of us a vote. Once most of the group taps the same option, it's decided. Nobody had to lead.

Trip Buddy is a Node.js app that runs on my laptop, with Gemma 4 running locally through Ollama as its brain. It is built for one specific group: six friends who meet in Delhi and leave from there.

Here's what it does:

Finds the long weekends. It reads the government holiday list for 2026 and 2027 and works out every window where a holiday joins a weekend.
Suggests bridge leave. Dussehra 2026 falls on a Tuesday, so taking Monday off turns it into a 4-day trip. In April 2027, one day of leave gets you 5 days off. That line alone is what makes people reply.
Plans three different trips. Gemma reads all six friends' preferences and suggests three trips with a different character each: hills, spiritual or nature, and heritage. Each comes with a day-by-day plan.
Emails everyone a personal vote. Each friend gets their own email. If Gemma picked an option with them in mind, that card says so.
Counts the votes. A tap on "I'm in" records the vote and shows a live tally. At 4 of 6, it announces the winner.
Runs on its own. The server checks every six hours and emails the group 21 days before each long weekend, so there's time to apply for leave and book trains.

It also knows when not to plan. Diwali is skipped both years, because nobody leaves home for a trip over Diwali.

Demo

I haven't sent it to the real group yet, so this demo uses test inboxes (Gmail + aliases) for all six friends. The votes below are mine, cast from each inbox to show the flow.

The email each friend gets. The subject line is the hook: "Dussehra: take 1 day off, get 4 days (Sat 17 – Tue 20 Oct)".

After everyone votes. One tap records the vote and shows the live tally.

Gemma planning the trip, locally. Valid on the first attempt, in under three minutes on my laptop.

The code finds long weekends and bridge leave.

Auto mode sending on its own.

Code

https://github.com/Princee215/Trip-Buddy

To run it yourself: install Ollama, run ollama pull gemma4, add your friends to data/friends.json, put a Gmail App Password in .env, and start node src/server.js.

Stack: Gemma 4 (open-weight, Apache 2.0) via Ollama, Node.js, Express, Nodemailer, Cloudflare quick tunnel. No database, no paid APIs.

How I Built It

The core design rule: the model plans, the code enforces. Gemma does the creative work. Plain JavaScript does everything that has a right answer.

Job	Done by	Why
Which dates are long weekends	Code	Dates have one right answer. A model guessing weekdays would be wrong sometimes.
Which leave days to suggest	Code	A scoring rule: each leave day must earn about 1.5 extra days off.
Group profile	Code	Interests ranked by how many friends share them; veg needs counted.
Where to go and what to do	Gemma	Picking places that balance six people's tastes is the creative part.
Checking Gemma's answer	Code	Three options, each with a name and a day plan, or it retries.
Emails, votes, schedule	Code	Nodemailer, Express, a six-hour check.

The pipeline, in order:

planner.js marks each day as off or work, groups off days into runs, and joins nearby runs when the gap fits within 3 leave days. For each cluster, it keeps an "easy" option (no leave) and a "bridge" option (best value with leave).
group.js turns six profiles into one group view.
prompt.js writes a brief for Gemma: the trip window, the month, the return deadline, preferences, and accuracy rules.
gemma.js calls Ollama's local API with format: "json", streaming on and thinking off.
generate.js checks the structure, fixes small things in the code (trims or pads the day plan), and saves the plan so it's only generated once.
email.js and send.js build a personal email per friend and send it through Gmail.
server.js records votes, shows the tally, and runs auto.js every six hours.

One rule in the prompt turned out to matter a lot: the group must be back in Delhi by 8 AM the morning after the trip, because it's a working day. Gemma works backwards from that, so the last day of each plan says when to leave.

What Broke Along the Way

Most of the interesting work was fixing things that went wrong.

My scoring formula hid the best deal of the year. The first version ranked trips by "days off per day of effort." It picked a plain 3-day weekend over Ram Navami plus Mahavir Jayanti in April 2027: 5 days off for 1 day of leave. I changed the score to days − 1.5 × leaves, so a leave day has to earn its place.

Node gave up after 300 seconds. My laptop took about 5 minutes per plan, and Node's built-in fetch times out if the server is silent for 300 seconds. Two fixes: streaming, so words arrive as they're written, and think: false, which skips Gemma's hidden reasoning. Plans dropped to under 3 minutes.

I told Gemma 14 hours was fine, so it decided everything takes 14 hours. When I allowed trips up to about 14 hours away, Gemma started saying Rishikesh takes 10–14 hours. It's about 5–6. The number in my prompt became an anchor. The fix was to say "closer places are equally good" and ask for the realistic travel time.

I turned preferences into rules, and my group would have corrected me. Four of six of us drink, so I told Gemma to avoid alcohol-free towns. That ruled out Rishikesh and Mathura, which are great trips for us. Same with "mountains": everyone likes them, but not every trip has to be in the hills. Now the prompt has exactly one firm rule. Everyone has to be able to eat, because three of us are vegetarian. Everything else is a preference Gemma weighs.

Strict checks made things worse. My validator retried whenever travel time or budget went slightly over. Each retry cost minutes, for a 1-hour difference. Now only broken structure triggers a retry; everything else is a note, or fixed in code.

Why Does Open Innovation Matter?

I could have called a closed API. Running an open-weight model locally made this project better in four specific ways.

It costs nothing to run, forever. This tool sends a handful of emails a year. Nobody in a friend group wants to pay a monthly API bill for that, and with Gemma on my own laptop, the cost is zero.

My friends' data stays with me. The tool knows each friend's budget, food habits, and whether they drink. That's the kind of thing friends tell each other, not a server they've never heard of. Here it never leaves my machine. The email footer says so.

The license lets me do anything with it. Gemma 4 is released under Apache 2.0, so I can modify, share, or build on it with no strings. To be precise: it's an open-weight model. The weights are open, but the training data isn't.

I can swap the model with one setting. The model name is a single environment variable. If a better open model comes out next month, I change one line.

The trade-off is real. A small local model gets local facts wrong, like Rishikesh travel times. It's also slower than a hosted API. That's exactly why the design keeps Gemma on the creative work and lets code handle anything with a right answer.

Limits and What's Next

The honest limits of this weekend version:

It only runs while my laptop is on. That's the price of keeping everything local. A cheap always-on box, like an old laptop or a Raspberry Pi, would fix it.
Vote links break if the tunnel restarts. I use a free Cloudflare quick tunnel, which gets a new URL every time. A named tunnel with a free account would keep the links stable.
Travel times are estimates. The email labels them "approx." and says to check before booking.
Holidays follow the central government list. Some friends' companies have their own holiday calendars.

What I'd add next:

A preferences form, so friends update their own profile instead of replying to the email
A "final plan" email the moment a trip wins the vote
Per-friend travel to Delhi, for friends who live in other cities
Grounding travel times with a search API, so Gemma stops guessing distances

Prize Categories

Best Use of Gemma: Gemma 4 runs locally through Ollama and does all the trip planning; nothing else in the project uses an AI model.

The next long weekend is Guru Nanak Jayanti in November. Trip Buddy will email the group about it on its own, three weeks ahead. This time, nobody has to be the one who plans.

DEV Community: Prince Singh