DEV Community: Ansh Meshram

Long Notice? Take It Slow. 🦥 Building NoticeNap with Open-Weight AI

Ansh Meshram — Thu, 22 Oct 2026 09:21:55 +0000

Built for Hacktoberfest 2026 — Week 3: Slow and Steady

Have you ever opened a recruitment notification, scholarship announcement, internship circular, or examination notice and discovered that the information you need is scattered across dozens of pages?

The deadline is somewhere in the middle. Eligibility criteria are buried in another section. Required documents, application fees, exceptions, and instructions are spread throughout the PDF.

You end up spending more time searching through paperwork than preparing for the opportunity itself.

Photo: Christian Holzinger on Unsplash.

What if one PDF upload could turn that overwhelming notice into a clear summary, a list of important dates, and an actionable checklist?

That is the idea behind NoticeNap — a local-first AI assistant designed to make reading long, information-heavy PDF notices less tedious.

🔗 Live frontend: https://noticenap.vercel.app

💻 Source code: https://github.com/AnshMeshram/NoticeNap

I built NoticeNap around the spirit of this week's Hacktoberfest theme: Slow and Steady — build open-source AI that rewards laziness.

Not laziness as an excuse to ignore important details, but as a reason to automate repetitive work and spend our energy where it actually matters.

🦥 The idea: One upload, a calmer plan

Official notices often contain everything an applicant needs to know, but finding those details manually can be frustrating.

NoticeNap is designed to turn a PDF notice into structured information that is easier to understand and act on.

Here is what the workflow aims to provide:

Quick summary: Understand the purpose of a notice without manually reading every page first.
Important dates: Identify application deadlines, examination dates, and other time-sensitive information when stated.
Eligibility criteria: Review qualifications, age limits, thresholds, and other requirements mentioned in the document.
Fees and required documents: Find application fees, exemptions, certificates, and supporting documents where specified.
Application steps: Turn instructions into a practical sequence of tasks.
Source references: Trace important findings back to their original PDF pages and supporting text when available.
Action checklist: Organize the next steps and track progress.
Export options: Save checklist items as Markdown and export valid dates to iCalendar where supported.
Document library: Revisit previously processed notices and find relevant documents where the corresponding functionality is available.

The goal is simple: instead of repeatedly asking, "Where was that deadline mentioned?", you can review the important information in one place and return to the original page whenever you need to verify something.

Photo: Sloth photo on Unsplash. Unsplash images are free to use under the Unsplash License; credit is appreciated.

NoticeNap is an aid for understanding and organizing notices. It is not a replacement for the official document.

🎯 Why this fits “Slow and Steady”

Consider a student applying for multiple scholarships or a job seeker tracking several recruitment notifications.

Each notice requires a similar sequence of work:

Open the PDF and scan its pages.
Find eligibility conditions and important dates.
Identify supporting documents and application steps.
Note the tasks that still need to be completed.
Return to the PDF whenever something is unclear.

NoticeNap aims to make that repeated workflow easier by organizing the information into one reviewable workspace.

The user still makes the important decisions. They decide whether they qualify, confirm the official deadline, and choose what to do next.

The AI handles the tedious first pass. The human stays in control of the final decision.

That is the kind of laziness I wanted to build for: less repetitive searching, less mental clutter, and more time for meaningful work.

⚙️ How NoticeNap works

NoticeNap combines PDF text extraction, a Python backend, and an open-weight language model served locally through Ollama.

The intended local processing pipeline is:

PDF upload → Text extraction → AI analysis → Structured results → Verification → Action checklist

1. Extract the PDF text

The application uses PyMuPDF (fitz) to extract readable text page by page.

Preserving page boundaries matters because a summary without a way to find its original source can be difficult to verify.

The extraction process maintains page references so that users can return to the relevant section of the notice when references are available.

2. Analyze the extracted content with local AI

NoticeNap uses Gemma 2 through Ollama for local, open-weight inference when the configured model service is available.

Instead of requiring every document to be sent to a closed, hosted-model inference API, the intended local setup sends extracted text to the configured Ollama service running in the user's environment.

The model is used to organize the notice into useful categories, including deadlines, eligibility, fees, documents, instructions, exceptions, and missing information.

3. Validate and organize the results

The backend uses Pydantic to validate structured data returned through the analysis workflow.

The important design principle is that missing information must not become an invented fact.

If a deadline, eligibility condition, or fee cannot be established from the available document content, the appropriate result should be marked “Not found” or “Needs verification”, rather than presented as certain.

4. Turn findings into actions

Finding information is only half the problem. The next step is remembering what to do with it.

NoticeNap organizes findings into a checklist, supports tracking task progress, and provides Markdown and calendar export functionality where implemented.

The intention is to connect document understanding with an actual workflow, rather than stop at a chatbot response.

🧰 The technology stack

Here is how the main components fit together.

Component	Technology	Purpose
Frontend	Next.js, React, TypeScript	Application interface and interactions
Styling	Tailwind CSS	Responsive layouts and visual styling
Backend	Python, FastAPI	Upload handling, APIs, and analysis orchestration
PDF extraction	PyMuPDF	Page-by-page text extraction
Open-weight AI	Gemma 2 through Ollama	Local summarization and structured extraction
Data validation	Pydantic	Validation of structured backend data
Exports	Markdown and iCalendar	Carrying action items into other workflows
Design workflow	Google Stitch	Screen design and interface references

The application is organized around a workspace with document analysis, action-list, and document-library experiences. The design uses a calm, paper-inspired visual style and a sloth mascot to reinforce the idea of making tedious work feel lighter.

🔓 Why open innovation matters for NoticeNap

For a project that processes recruitment notices, scholarship applications, university circulars, and similar documents, where the document is processed matters almost as much as what the model produces.

A notice may contain personal application details or information a user would rather not send to an external inference service.

With the intended local configuration, NoticeNap can run the document-processing and model-inference path using components installed in the user's own environment:

The PDF is processed by the local backend.
PyMuPDF extracts its readable text.
The backend sends that text to the configured local Ollama service.
Gemma 2 generates the analysis.
The application validates and displays the structured result.

In this configuration, the extracted PDF text does not need to be sent to a third-party model inference API.

Open-weight AI also gives developers more control over model selection and the execution environment. The project can evolve without making a single closed-model API the foundation of its design.

There are trade-offs, of course. Local inference requires suitable hardware, installation, and configuration. Downloading a model initially requires internet access, and model performance depends on the available resources and the document being processed.

I do not consider a local model automatically better at every task. The advantage here is control over the processing environment and the freedom to build around an open-weight model.

A note about deployment

The public Vercel URL is a frontend preview, not proof that the complete AI workflow is available as a hosted service.

A browser visiting that frontend cannot automatically connect to Ollama running on the developer's or visitor's computer. End-to-end processing requires the frontend, FastAPI backend, and model runtime to be configured and reachable in the intended environment.

For the local-first workflow, those components need to be set up together.

I think this distinction is important: a project should be transparent about what its interface demonstrates and what its underlying infrastructure actually supports.

🛡️ Designing for trust, not just convenience

An incorrect deadline or eligibility condition can have real consequences for an applicant.

That makes reliability an important part of NoticeNap's design.

The project emphasizes several safeguards:

Traceability: Retain source-page references and supporting excerpts when available.
Explicit uncertainty: Flag information that is missing or needs verification.
Structured output: Validate the shape of extracted information before presenting it.
Human verification: Encourage users to check consequential details against the official notice.
Clear processing status: Distinguish model-based analysis from a rule-based fallback when the model service is unavailable.

These safeguards do not eliminate mistakes. Language models can misinterpret content, and source references do not guarantee that an interpretation is correct.

Scanned, image-only PDFs may also require OCR because ordinary text extraction cannot reliably read text that exists only as an image.

That is why the original PDF remains the authoritative source.

🧪 What I am paying attention to during testing

A useful document assistant needs to handle more than the ideal case.

The project includes a functional test plan covering scenarios such as:

Extracting text from valid, multi-page PDFs while preserving page references.
Handling notices where dates or eligibility information are absent.
Providing clear feedback for invalid uploads and scanned documents that need OCR.
Detecting unavailable Ollama services or missing models.
Handling malformed model output instead of treating it as a successful analysis.
Checking that calendar exports contain only validated dates.
Evaluating whether Hindi and Marathi explanations preserve names, numbers, dates, and exceptions accurately.

These are important because a polished summary is not enough if the underlying details cannot be trusted.

The next improvements I would prioritize are stronger extraction evaluations, better OCR support, more comprehensive multilingual testing, improved evidence traceability, and a securely configured end-to-end deployment.

🚀 Run NoticeNap locally

The project setup uses Node.js 20 or newer, Python 3.11 or newer, npm, and Ollama, along with hardware capable of running the selected model.

1. Clone the repository

git clone https://github.com/AnshMeshram/NoticeNap.git
cd NoticeNap

2. Install and start Gemma 2 with Ollama

ollama pull gemma2
ollama serve

Keep Ollama running in its own terminal.

3. Install the backend dependencies

From the repository root, create and activate a Python virtual environment.

On Windows PowerShell:

python -m venv .venv
.\.venv\Scripts\Activate.ps1

On macOS or Linux:

python -m venv .venv
source .venv/bin/activate

Then install the dependencies and start FastAPI:

pip install -r backend/requirements.txt

python -m uvicorn backend.main:app \
  --host 127.0.0.1 \
  --port 8000 \
  --reload

4. Start the frontend

Open another terminal:

cd frontend
npm install
npm run dev

Open the application at:

http://localhost:3000

Configuration matters: Check the repository's environment examples and current source code to ensure the frontend points to the local FastAPI backend and the backend uses the intended Ollama endpoint and model. The commands above follow the project's documented setup; verify the current repository if any paths or configuration names have changed.

Source code: https://github.com/AnshMeshram/NoticeNap

💭 What I want NoticeNap to become

I want NoticeNap to help people spend less time hunting through paperwork and more time acting on opportunities.

A long recruitment notice should become easier to review. A scholarship announcement should become easier to turn into a list of tasks. A university circular should be easier to understand without losing sight of its original requirements.

There is still work to do, particularly around OCR, extraction reliability, multilingual accuracy, evidence validation, and deployment.

But I believe this is a useful place for open-source AI: a real, repetitive problem where local inference, structured extraction, and a thoughtfully designed workflow can work together to reduce unnecessary effort.

The best automation is not necessarily the one that does everything without supervision. Sometimes it is the one that removes the frustrating parts while keeping the important decisions in your hands.

Let the notice be long. Your to-do list shouldn't. 🦥

🤝 Feedback and contributions

I'd especially welcome ideas and contributions around PDF extraction accuracy, OCR for scanned notices, evidence-backed summaries, multilingual evaluation, accessibility, and reliable local-first inference.

Explore the project:

Live frontend: https://noticenap.vercel.app
GitHub repository: https://github.com/AnshMeshram/NoticeNap

If you were building a local AI tool to automate one repetitive task in your daily life, what would you build?

Created for Hacktoberfest 2026 — Open-Source AI Challenge, Week 3: Slow and Steady.

From Leftover Rotis to Better Margins: Building DabbaIQ with Open-Source AI

Ansh Meshram — Sat, 17 Oct 2026 08:10:26 +0000

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

A kitchen rarely loses money in one dramatic moment. Sometimes it leaks out one extra batch of rice, one ingredient bought too late, or one tray of food that nobody counted after lunch.

For a small tiffin business, those decisions are connected. Demand affects preparation. Preparation affects stock. Stock and recipes affect cost. Sales and leftovers should affect tomorrow’s plan. But in a busy kitchen, those facts often live in different notebooks, spreadsheets, or someone’s memory.

I’m building DabbaIQ to connect those decisions in one kitchen operations desk.

The guiding idea is simple: Cook the right amount. Waste less. Earn more.

What I Built

DabbaIQ is an AI-assisted kitchen operations platform designed for Indian tiffin services, meal-subscription businesses, small caterers, and cloud kitchens. It brings together the daily workflows that decide whether a kitchen runs smoothly—and whether the economics make sense.

Preparation planning: organize demand inputs, preparation quantities, safety buffers, and ingredient availability before the rush.
Inventory and procurement: track ingredients, spot low-stock risks, and support supplier or market-price discovery.
Recipe costing: connect ingredient quantities to estimated per-portion and per-dabba costs.
Sales and dispatch: record what went out, instead of treating production as proof of sales.
Waste tracking and reporting: record leftovers and compare operational outcomes to help inform the next shift.

The product also has a visual identity rooted in the dabba itself: a stainless-steel four-tier tiffin. The introduction follows a scroll-driven, tier-by-tier sequence, using each layer to introduce part of the system. It’s a product explanation, not just a generic dashboard with an AI badge added to it.

DabbaIQ is a working software project, but I’m not claiming that it has already reduced waste by a measured percentage or generated revenue for a paying kitchen. Those are outcomes to validate with operators—not numbers to invent for a launch post.

Demo

Live frontend: https://dabba-iq.vercel.app/

The frontend is deployed. I’m completing production checks on the backend’s database access, cross-origin configuration, and AI endpoint so I can verify the complete workflow—not just the interface. Until those checks pass, treat the link as a preview and not a guarantee that every backend-connected action is working end to end.

Code

GitHub repository: https://github.com/AnshMeshram/dabbaiq

AnshMeshram / DabbaIQ

AI-powered kitchen prep & food waste planner for tiffin services and caterers. Cuts food waste with smart demand forecasting, live SerpAPI wholesale ingredient price discovery, MongoDB Atlas persistence, and resilient Temporal-orchestrated preparation workflows.

🍱 DabbaIQ — AI Kitchen Prep & Food-Waste Planner

"Cook the right amount. Waste less. Earn more."

An enterprise-grade, open-weight AI kitchen operations desk built for Indian tiffin subscription services, cloud kitchens, and meal prep entrepreneurs. Designed from a 26-screen Google Stitch canvas, pairing deterministic demand forecasting with Gemma 3 open-weight reasoning.

🚀 Live Web App (Vercel) • 🍱 3D Tiffin Experience • 📐 Architecture • ⚡ Quickstart • ☁️ Deployment • 🧪 101/101 Tests

📑 Interactive Table of Contents

Click to expand / collapse navigation

View on GitHub

How I Built It

DabbaIQ is split into a web interface, an API layer, operational data, and optional intelligence/workflow services.

Frontend: Next.js, React, TypeScript, and Tailwind CSS.
Backend: Python and FastAPI.
Application data: MongoDB Atlas.
Open-weight AI path: Gemma 2 through Ollama for supported local-inference and kitchen-assistance workflows.
Market research integration: SerpAPI for supplier and market-price discovery.
Time-series capabilities: Tiger Data/TimescaleDB for historical data workflows.
Workflow orchestration: Temporal integration for processes that benefit from coordinated execution.

The most important design decision is the boundary between calculation and interpretation. Ingredient quantities, stock counts, arithmetic, and report totals should be derived from structured records and application logic. A language model can help interpret an unstructured kitchen note, explain a recommendation, or make a plan easier to understand; it should not be allowed to make up stock counts or quietly replace a calculation.

That boundary is what makes an AI tool useful in an operational setting. A fluent answer is not enough if the number behind it is wrong.

The system is designed as a feedback loop: records inform a plan; the kitchen executes it; sales and leftovers become new records. The value is not one isolated prediction. It is making the next decision with better context than the previous one.

Why Does Open Innovation Matter?

For a small business, the model choice is not just a technical preference. It affects operating cost, deployment choices, control over data flow, and how much the product depends on one provider.

Gemma 2 is an open-weight model. Running it through Ollama gives the project a path to local inference in environments where the model, hardware, and configuration are available. That makes it possible to experiment with the model locally, inspect the surrounding application code, and change the inference setup without rebuilding every product workflow around a single closed API.

Open-weight does not automatically mean free, private, or production-ready. Local inference still uses hardware. A hosted service still needs a reachable, secured model endpoint. And a privacy promise is only as strong as the actual data flow. I want DabbaIQ to make those deployment choices explicit rather than market “AI” as magic.

The open approach also lets the system keep its most important business rules outside the model. The database and deterministic calculations remain the source of truth; the model adds assistance where language and context are useful. That separation makes it easier to test, replace, and improve individual components over time.

Why This Could Be a Side Hustle

DabbaIQ is aimed at a narrow customer, on purpose: an independent kitchen that has outgrown notebooks but cannot justify a large restaurant-management system.

Potential customers include:

Tiffin and meal-subscription operators preparing recurring batches.
Small caterers coordinating ingredients, portions, and dispatch.
Cloud kitchens trying to understand ingredient cost and leftovers.
Meal-prep businesses that need a clearer link between sales and preparation.

The business model I would test first is a per-kitchen monthly subscription, with a simple entry tier for planning and stock visibility and a higher tier for costing, reporting, and more advanced assistance. An initial price experiment might be ₹499–₹999 per kitchen per month—but that is a hypothesis to test, not a price customers have agreed to pay.

The value proposition should be measurable. During a pilot, I would compare planned portions with actual sales and leftovers across several shifts, record how often stock shortages disrupt preparation, and ask the operator whether the tool saves enough time or money to justify paying for it. If it cannot show that value, the product needs to improve before the pricing does.

What I’m Validating Next

I don’t have a paying pilot or verified savings figures to report yet, and I won’t manufacture a testimonial or ROI claim. The next milestone is to work with a real kitchen operator and test the workflow against real shift records—with permission, and without exposing customer or business data unnecessarily.

The immediate engineering work is equally practical: verify MongoDB connectivity in the deployed environment, allow the correct Vercel origin through CORS, and make sure the configured Ollama/Gemma endpoint is reachable before presenting AI features as online. A deployment is not complete just because the homepage loads; the critical actions have to work too.

My success metric is not whether the model writes an impressive explanation. It is whether a kitchen owner can make a better preparation or purchasing decision because DabbaIQ connects information that was previously scattered.

Prize Categories

I’m submitting for the overall Side Hustle challenge. I’ll select a partner prize category only where the corresponding technology is meaningfully integrated and can be demonstrated in the final build—not simply because a dependency appears in the repository.

Closing Thought

A small kitchen doesn’t need AI for the sake of AI. It needs fewer avoidable surprises: fewer last-minute stock gaps, a clearer cost per dabba, and a more useful account of what happened after the lunch rush.

That’s the problem I’m building DabbaIQ for. The next step is to test it with the people who live that problem every day.

Live frontend: https://dabba-iq.vercel.app/

Source code: https://github.com/AnshMeshram/dabbaiq

Trailnote: Plan the Walk. Make the Note. Put the Phone Away.

Ansh Meshram — Thu, 08 Oct 2026 09:03:53 +0000

🌿 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.

devchallenge #hf26challenge #gemma #opensource

PackPal - Local AI Travel Companion

Ansh Meshram — Mon, 05 Oct 2026 07:02:17 +0000

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

What I Built

PackPal is a local-AI travel companion built for a friend who wanted a simpler way to organize trips with friends. It combines personalized packing lists, weather/activity-aware recommendations, smart luggage optimization, itineraries, travelers, and group expense splitting in one place.

PackPal uses Gemma 2 through Ollama for local AI reasoning, while deterministic TypeScript handles calculations such as luggage weights and expense settlements.

Demo

🚀 Live Demo: https://pack-pal-tau.vercel.app/

Code

💻 GitHub: https://github.com/AnshMeshram/PackPal

How I Built It

PackPal is built with Next.js, React, TypeScript, Tailwind CSS, MongoDB Atlas, SerpApi, Ollama, and Gemma 2.

Gemma 2 is at the core of the application and handles:

🎒 Personalized packing recommendations
🧳 Luggage optimization
🏃 Activity-to-packing reasoning
🔄 Natural-language trip changes
💸 Natural-language expense extraction
🗺️ Destination interpretation

The architecture separates AI reasoning from deterministic application logic:

Gemma understands and recommends → TypeScript validates and calculates.

For example, Gemma extracts information from:

"Rahul paid ₹1,800 for dinner for everyone."

Then PackPal's deterministic expense engine calculates the actual balances and settlements.

SerpApi provides live travel/search context, MongoDB Atlas provides persistence, ElevenLabs enables optional voice output, and Sentry provides monitoring.

Why Does Open Innovation Matter?

PackPal was intentionally built around open-weight AI and local inference.

Running Gemma 2 through Ollama means the core AI can run locally instead of requiring every request to be sent to a closed AI API.

This provides:

🔐 Greater privacy for personal trip information
💰 Lower recurring AI inference costs
📴 Potential for offline/local usage
🔄 Freedom to swap or upgrade models
🛠️ More control over how the AI behaves

For a personal travel assistant, keeping sensitive trip and group information under the user's control is especially valuable.

My Agent Session

DevRelay agent session: https://dev.to/agent_sessions/packpal-privacy-first-ai-travel-journal-packing-companion-430lto

Prize Categories

🏆 Best Use of Gemma — Gemma 2 is the core AI model powering PackPal.
🔎 Best Use of SerpApi — Provides live search and destination context.
🗄️ Best Use of MongoDB Atlas — Persistent application data layer.
🎙️ Best Use of ElevenLabs — Optional voice generation.
🛡️ Best Use of Sentry Agent Tracing — Monitoring and debugging.

devchallenge #weekendchallenge #hf26challenge