DEV Community: Sarvesh

I Built a Travel Agent That Plans With You and Travels Along Virtually

Sarvesh — Sat, 07 Nov 2026 09:57:02 +0000

A family group chat is a surprisingly difficult place to put an AI agent.

One person wants to visit every landmark. Someone else wants less walking. Food preferences appear halfway through the conversation. A ticket screenshot gets buried under twenty messages.

Then the flight gets delayed.

Suddenly, “make us an itinerary” becomes a much more interesting problem:

Can an assistant understand the conversation, remember who needs what, check real information, explain the trade-offs, and recover when things change?

That question became Trippy, my family travel companion built with Switch, Telegram, and Python.

This was my first time building with Switch. I started with a travel-assistant idea and ended up learning much more about agent coordination, evidence, identity, and failure recovery than I expected.

Explore Trippy on GitHub

The family should talk naturally. The system should behave carefully.

I wanted Trippy to work where my family already talks: Telegram.

A request should sound like this:

“Compare two outings tomorrow, starting from Mecca Masjid and visiting Charminar. Make Chowmahalla Palace an optional extra stop, consider the weather, and show the comparison visually.”

The family should not need to know which agent handles weather, which tool calculates routes, or which command opens memory.

Behind that simple request, however, several things need to happen:

Resolve the places and requested date.
Retrieve walking routes and relevant weather.
Apply saved preferences and constraints.
Compare the options.
Explain missing information.
Return a readable answer and visual.

The interface stays conversational. The implementation needs structure.

My central architectural decision was:

Agents propose. Application code validates and controls execution.

Why Switch became the backbone

The part I appreciated most about Switch was that it gave the agents a place to collaborate around an actual conversation.

Trippy uses a Telegram connector for the family-facing chat and a separate private Switch workroom for internal assignments.

That separation matters. The family gets readable replies instead of a stream of agent JSON, tool requests, and internal commentary.

The model roles communicate with the Coordinator through structured messages. Switch carries those interactions; my application checks what they mean and whether they are allowed.

Family Telegram group
          ↕
       Switch
          ↕
 Python Coordinator ───── SQLite
          ↕
 Private Switch workroom
          ↕
 Planner and specialist roles

For a first Switch project, this was a satisfying discovery: I could focus on the travel workflow while using a shared communication layer for Telegram messages, agent assignments, and media.

Switch made the collaboration practical. The Coordinator made it controlled.

Those responsibilities complement each other.

Six roles, without six agents talking at once

Trippy has three core roles and three optional specialists.

The Coordinator is deterministic Python application code. It is not another model improvising what should happen next.

Role	Responsibility
Coordinator	Routing, identity checks, state, validation, approvals, and delivery
Planner	Conversation, permitted tool requests, and proposed changes
Reservation	Requests execution of approved simulated reservation changes
Researcher	Gathers bounded evidence when a request needs focused research
Mediator	Explains compromises between computed options
Watcher	Assesses relevant sourced weather events

The optional specialists join only when useful.

A weather question can follow the direct Planner-and-tool path. A more involved comparison may benefit from research or mediation.

Researcher and Mediator handoffs are bounded, and they share the discussion’s tool budget. Delegation does not create an unlimited new allowance or an endless agent conversation.

The Mediator also cannot make an infeasible option acceptable through persuasive wording. It explains existing computed options; hard constraints remain enforced by code.

More roles should mean clearer responsibilities, not more noise.

A recommendation needs evidence behind it

Travel recommendations are easy to make sound convincing.

“Just walk there—it’s nearby.”

But nearby for whom? Using which route? Does that include walking inside the venue?

Trippy integrates:

Open-Meteo for weather.
OpenStreetMap data, through Nominatim and Overpass, for places and available tags.
Routing services for mapped journey estimates.

Tool results are saved as evidence. Model replies declare factual claims against specific fields in that evidence.

For example, a walking-distance claim can point to:

/plans/0/walking_m

The backend checks the declared value against the stored result before rendering the sourced fact.

Forecast dates matter too. A forecast for today does not answer a question about tomorrow simply because the temperature looks plausible.

There are deliberate boundaries here. Field-level validation does not prove every sentence true, and an OpenStreetMap accessibility tag is not a guarantee.

If venue walking, stairs, or current opening status are unknown, the answer should expose that uncertainty.

“I don’t have enough evidence” is a useful planning result.

Memory should remember who said what

Personalization becomes unreliable when an assistant remembers a preference but forgets its owner.

“Dad prefers less walking” is different from “I prefer less walking.” A nickname is also different from a verified identity.

Trippy separates those concepts.

Saved preferences can retain an owner or reporter, source-message evidence, timestamps, importance, and whether the preference is a hard or soft constraint.

The interaction changes with the consequence:

“Call me Sarvesh.”

A display-name update happens directly.

“I prefer vegetarian meals.”

A clear personal soft preference can save with an undo option.

“I must walk at most 800 metres.”

A hard limit requires confirmation because it changes which plans are allowed.

Memory inspection makes stored information visible, and conflicting corrections can show the previous and proposed values.

Group privacy adds another boundary. Sensitive mobility, health, and expense requests need explicit sharing permission before group processing.

One lesson from testing: a technically correct privacy rejection can still be a terrible conversation. Trippy now gives clearer guidance instead of exposing a cryptic internal error.

A dependency graph, stored in SQLite

I considered whether itinerary relationships needed a graph database.

For Phase 1, they did not.

The useful structure is straightforward:

Flight arrival
      ↓
Airport transfer
      ↓
Hotel check-in
      ↓
Dinner

SQLite stores itinerary items and dependency edges in relational tables. A recursive query finds downstream items affected by a disruption.

Separate tables hold discussions, tool jobs, preferences, proposals, actions, processed events, and outgoing messages.

This gives the project graph-style traversal alongside ordinary transactions, foreign keys, and versioned Alembic migrations.

For a single local Coordinator, that is a practical fit. A server database becomes a stronger choice when deployment and concurrency requirements demand it.

I wanted the architecture to earn its complexity.

Disruption recovery has an approval boundary

A simulated flight delay is one of Trippy’s most revealing demonstrations.

The disruption identifies affected dependencies and starts repair planning. The proposal shows the intended changes, including timings, cost differences, alternatives, and expiry.

Then the family reviews it.

Execution requires the exact proposal approval from an authorized linked account. The application checks identity, scope, expiry, and replay protection.

A friendly “sounds good” does not become permission to spend money.

Reservation actions are currently simulated. No real supplier booking or payment occurs.

That boundary lets me demonstrate the workflow honestly while building the fundamentals needed before introducing higher-consequence integrations.

The most useful debugging lesson: good data can still produce a bad experience

One outing request successfully fetched routes and weather—and still failed.

The weather was nested inside the comparison result. The reply validator expected it through the weather contract and could not see it.

To the user, the assistant looked broken. Underneath, the provider calls had succeeded.

The fix was to expose the exact stored forecast through the same dated evidence contract used by a standalone weather request.

Testing also revealed that “show comparison visually” was being missed by the visual-request check.

These were integration failures between otherwise working components.

I added a recovery path: when the computed comparison exists but the extra narration fails or times out, Trippy can deliver that request’s saved comparison and requested schematic, with limitations visible.

It does not substitute an unrelated fictional plan.

That became a broader design principle:

A failure in generated narration should not automatically discard useful computed results.

Reliability needs more than a convincing reply

Trippy uses a durable inbox and outbox to separate message processing from delivery.

Processed event IDs prevent duplicate handling. Unique action keys protect against duplicate local execution. Assignment IDs, trip versions, and deadlines help reject stale results.

Uncertain delivery is held for review rather than blindly resent.

I am not claiming exactly-once Telegram delivery. I am making delivery state visible and giving the application a controlled recovery path.

The latest local suite passed 233 tests. The project also includes deterministic scenario checks and a process-crash recovery demonstration.

Those checks establish application behavior under controlled conditions. They are not a substitute for evaluating realistic family conversations.

The dashboard helps connect both worlds: itinerary dependencies, evidence, verification records, proposal history, and delivery state can be inspected behind the chat.

Phase 1 is the foundation

Trippy already brings together conversation, sourced outing comparisons, accountable memory, image understanding, expense bookkeeping, reminders, visual plans, calendar exports, and simulated disruption recovery.

But this is Phase 1, not the finished product.

My next priorities are:

Test more real multi-person conversations, including Hinglish, ambiguous references, and corrections.
Improve provider fallbacks while preserving source and freshness labels.
Gather better venue-level accessibility, walking, opening-hour, and rest information.
Expand deployment monitoring and conversation-quality evaluations.
Explore real travel-status events and booking handoffs with proper reconciliation.

Trying Switch for the first time helped me move beyond “an AI that answers travel questions” toward a system where agents collaborate through explicit workflows.

That is the part I am proudest of.

The family gets one companion to talk to. Underneath, the system keeps track of evidence, ownership, decisions, and what actually happened.

Check out Trippy’s code, architecture, and setup guide.

I Built an AI Food Scout Because “What Should I Eat?” Is a Surprisingly Hard Question 🍜

Sarvesh — Sun, 25 Oct 2026 12:44:32 +0000

This is a submission for the "Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady" (https://dev.to/challenges/hacktoberfest-week3-2026-10-19)

You know the drill.

You're hungry. You have a budget. Maybe you're trying to hit a protein target, stay under a calorie limit, or just eat something other than the same three meals you've been ordering for weeks.

You open a food delivery app and start scrolling.Twenty minutes later, you've seen 47 dishes, opened six restaurant pages, and still have absolutely no idea what to order.

The problem isn't a lack of food choices. It's having to do all the work of finding the right ones.

That's why I built CraveCode, an AI-assisted food discovery system that searches for meals around your preferences, filters unsuitable options, and ranks the remaining choices.

The goal? Less scrolling, less guesswork, and more time enjoying the food.

What I Built

CraveCode helps answer a deceptively difficult question:

What can I eat that fits my goals, preferences, and budget?

Instead of starting with a restaurant catalogue, you start with a meal brief.

You can specify your dietary preference, protein target, calorie ceiling, budget, preferred cuisine, meal timing, and the kind of food you're craving.

CraveCode then discovers candidates, filters them against your requirements, ranks them, and diversifies the results.

What makes it different?

Adaptive discovery: It starts with two menu queries in parallel and can expand to a maximum of four initial discovery queries when the results lack sufficient variety or coverage.
Constraint-aware filtering: It filters known unsuitable options, including incompatible dietary flags, explicit exclusions, and items priced above your budget.
Ranking beyond relevance: It considers factors such as query relevance, dish-family matches, price, stock status, and available restaurant feedback.
Less repetitive recommendations: It removes duplicate items from the same restaurant and penalizes repetitive choices to encourage variety.
Explore more: An, locally served Gemma model suggests additional dish-search terms when you want to discover beyond the initial results.
Evidence over guesswork: Public web results are treated as discovery leads, not verified live menu items. Uncertain prices and broad nutrition estimates are not presented as confirmed facts.

The system can return up to 15 ranked options, with the actual number depending on the candidates available.

The interesting part isn't simply that an AI recommends food. It's that the application combines search, explicit constraints, deterministic ranking, and optional AI exploration rather than asking a language model to invent the entire answer.

Demo

Try it: "CraveCode live preview" (https://cravecode.onrender.com)

Watch the demo: yt demo

A note about the render preview: The public Render preview uses SerpApi for public web discovery. The richer signed-in Swiggy menu-search experience is supported through the local setup(As it requires swiggy production access which is under process). These are different discovery modes, and a public search result does not guarantee current availability or a verified menu price.

The quickest way to understand CraveCode is to see a complete search:

Enter a meal brief with a budget and nutrition goals.
Watch the system discover and rank relevant options.
Inspect the returned dishes, prices, and evidence labels.
Use Explore more to look for additional dishes.

Code

GitHub repository: "SarveshDujari/CraveCode" (https://github.com/SarveshDujari/CraveCode)

CraveCode is built with React, Vite, Node.js, TypeScript, and Mastra, with integrations for Gemma, MongoDB Atlas, SerpApi, and Render.

Explore the repository to see how the search workflow, candidate filtering, ranking logic, and optional AI-powered dish expansion fit together.

How I Built It

I didn't want CraveCode to be a chatbot that returns a convincing paragraph about food and leaves the user to verify everything.

I wanted a system that actually searches for candidates, applies rules, and explains what it knows.

Here's the simplified architecture:

             Meal brief
                 |
                 v
         React + Vite UI
                 |
                 v
      Node.js / TypeScript API
                 |
                 v
          Mastra workflow
      Plan -> Discover -> Verify
                 |
         +-------+-------+
         |               |
         v               v
     Swiggy MCP        SerpApi
   Local menu search   Public discovery
         |               |
         +-------+-------+
                 |
                 v
        Normalize candidates
                 |
                 v
       Filter -> Score -> Diversify
                 |
                 v
         Ranked recommendations

      Extra integration:local Gemma, MongoDB Atlas

Mastra: orchestrating the discovery workflow

Mastra provides the workflow structure for planning discovery, retrieving candidates, and processing the results.

The key design decision is that orchestration doesn't own every business rule. The workflow connects the discovery stages, while the application code handles important eligibility checks and ranking decisions.

That makes the system easier to inspect, debug, and improve than a single prompt responsible for the entire process.

Swiggy MCP: searching actual menus

The signed-in local setup can use Swiggy MCP to search menus associated with a saved delivery address.

This enables a richer discovery experience using returned menu information, including prices and availability-related signals where provided.

I keep this distinct from the hosted preview. The existence of a restaurant page is not equivalent to a confirmed, currently orderable menu item.

SerpApi: a public discovery fallback

The Render preview uses SerpApi to find relevant, city-specific Swiggy pages.

The application checks query relevance, retains suitable delivery-page URLs, and removes duplicates and generic results.

These results are treated as leads for discovery, not as verified menu data. That distinction matters because a search engine cannot guarantee a dish's current price, stock, nutrition, or delivery eligibility.

Gemma: an local AI feature

CraveCode uses a locally served Gemma model for the Explore more dishes feature.

Instead of asking the model to rank every item or decide whether a meal satisfies every hard constraint, I use it for a focused task: proposing additional dish-search terms.

The application validates those suggestions against an allowlist and structured-output requirements. If the output is malformed or unsuitable, deterministic fallback choices are available.

This keeps the AI feature useful without making the entire application dependent on a model endpoint.

MongoDB Atlas: persistence and usage controls

MongoDB Atlas supports persistence for completed searches, candidates, and shared usage-budget counters.

Those counters are especially important when the public preview relies on an external search service. If the hosted budget store is unavailable, paid SerpApi requests are stopped rather than proceeding without the intended shared budget protection.

Render: making the project accessible

Render hosts the public preview, so people can try the interface without setting up the full local environment.

The deployment has its own limitations, particularly around signed-in menu access. Documenting those limitations makes the demo more honest and helps developers understand what they need to reproduce the richer local experience.

The engineering principle tying it together

The model proposes. The application checks. The evidence determines what can be claimed.

For example, a model-generated dish idea still needs to pass through the discovery pipeline. A public search result doesn't become a verified menu item just because it looks relevant. And a broad nutrition estimate doesn't become a restaurant-specific nutritional fact.

That separation is the core of how I approached the project.

Why I Didn't Let AI Decide Everything

An LLM can suggest the perfect meal, but it can't guarantee that the dish is available, affordable, or nutritionally accurate.

So I split the responsibilities: Gemma explores new dishes, search discovers candidates, and deterministic code handles filtering and ranking. Uncertain prices and nutrition estimates remain just that: estimates.

This made CraveCode easier to debug and gave me more control over its recommendations.

What I'd improve next

Nutrition is the biggest opportunity.
CraveCode currently uses broad, hand-authored nutrition ranges for supported dish types. They are estimates, not verified values for a particular restaurant's recipe or serving.

I'd like to improve that with more reliable item-level nutrition data, stronger evaluation of live discovery, and clearer verification of final payable prices and availability.

Also would like to add the swiggy integration to render after getting approval.

The Lazy Payoff

The intended payoff is straightforward: less manual searching, less repetitive scrolling, and fewer unsuitable choices to inspect.

Instead of separately browsing restaurant pages, checking every dish against a budget, and comparing a long list of similar items, a user can start with their constraints and receive a filtered, ranked shortlist.

The right way to measure this would be to compare the time needed to find a suitable meal manually against the time needed with CraveCode, across several realistic meal briefs.

Prize Categories

Best Use of Render: the deployed public preview.
Best Use of Gemma: optional local model inference for additional dish discovery.
Best Use of Mastra: the structured discovery workflow.
Best Use of MongoDB Atlas: persistence and shared search-usage controls.
Best Use of SerpApi: public web discovery for the hosted preview.

Try CraveCode

Live preview: https://cravecode.onrender.com

GitHub: https://github.com/SarveshDujari/CraveCode

Demo video: [https://youtu.be/DoDybTKEgkY?si=wDeZN4zPQzU3ZKSR]

Cheers!

The inspection machine was working. The order was still late. So I built FactoryGraph.

Sarvesh — Sun, 18 Oct 2026 14:27:06 +0000

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

What I Built

A machine breaks down at eight in the morning.

There is another machine in the workshop. The inspection bench is working. People are available.

So why might the customer’s order still arrive late?

Because those facts, individually, don’t tell you whether recovery is possible. The replacement machine might already be booked. The available worker might not be qualified to use it. Inspection might be waiting for parts that haven’t been made yet.

That connected problem is what I wanted to explore with FactoryGraph, a factory operations copilot for small manufacturers.

An operator configures the factory, reports a breakdown, and gets a traceable view of the consequences. FactoryGraph compares feasible recovery options, estimates their operational costs, and shows the assignments that would change.

The operator reviews and approves the response. After the repair, its actual outcome becomes evidence for future planning.

FalkorDB connects the factory. Deterministic rules calculate the options. Local Gemma helps explain them. The operator approves the changes.

Caption: Waiting and recovery are compared using the same configured factory assumptions. The proposed assignments remain unchanged until approval.

Who would pay for this?

My starting audience would be owners and production supervisors at small machining or fabrication workshops: businesses with a few connected production stages, qualified operators, and customer deadlines to protect.

The service I would offer is factory setup plus ongoing planning support.

The initial work would involve mapping their machines, dependencies, shifts and cost assumptions. The recurring value would come from helping them evaluate disruptions and retain useful repair and supplier history.

A pricing experiment I would test is:

Offering	Proposed price	What the customer receives
Assisted setup	₹4,999 or $53 once	Help configuring one workshop and validating its initial assumptions
Workshop plan	₹1,499 or $16/month	Application updates, support and periodic configuration reviews
Integration work	Quoted separately	Future imports or connections to existing operational systems

These are hypotheses, not validated prices. I haven’t established willingness to pay, and there is no billing integration in the current application.

Before adding checkout, I would want a workshop to use the product and answer a more important question: does this make their next recovery decision easier?

Demo

The recording starts with the guided walkthrough, then moves into the full operational workspace.

The example is deliberately small enough to follow:

CNC One stops at 8 AM.
The estimated repair takes two hours.
Cutting affects inspection.
The customer needs the brackets by 2 PM.
Waiting projects a 3 PM finish.
The demonstrated recovery projects completion by 2 PM.

In this synthetic configuration, the waiting baseline is ₹4,000, compared with ₹3,750 for the selected recovery: ₹250 in estimated cost avoided.

That is a result from configured demonstration rates, not measured savings from a real factory. The customer order’s ₹40,000 value is also separate from the estimated operational loss.

Why I added a Guide

While preparing the demo, I realised I needed help explaining my own interface.

The application had the pieces, but moving between screens didn’t automatically explain how those pieces belonged together.

That led to the eight-step Guide:

Factory → Breakdown → Impact → Recovery → Approval → Repair → Restoration → Memory

It uses the actual application APIs and saved proposals in a separate practice factory. The walkthrough is another way to use the workflow, rather than an animation showing a predetermined success.

Caption: Inspection needs finished parts. Showing that dependency first makes the later disruption easier to understand.

The full workspace separates the operational responsibilities:

Section	The question it answers
Exposure	How is this factory configured, what could the disruption cost, and which recovery should we review?
Floor	What work is assigned to each machine, and when?
Impact	Which connected stages and customer orders are affected?
Materials	Are stock availability or supplier deliveries constraining recovery?
Memory	What happened previously that could inform the next estimate?

FactoryGraph currently runs locally. The video demonstrates the application with synthetic factory data; live machinery integration is future work.

Code

The implementation, setup instructions, architecture and tests are available here:

SarveshDujari / FactoryGraph

FactoryGraph

When a machine stops, understand the impact before making the next move.

FactoryGraph is a factory operations copilot for small manufacturers. It connects machines, production stages, qualified workers, materials and customer orders in FalkorDB, traces the consequences of a breakdown, calculates feasible recovery options and estimated financial exposure, and lets an operator approve the response.

Connected factory context · Deterministic planning · Human approval · Sourced memory · Local Gemma briefings

This repository contains a working local demonstration with synthetic factory data. Financial results are estimates from configured rates. Machine-health readings are explicitly simulated.

The problem

A…

View on GitHub

Browse the FactoryGraph repository

For the most interesting implementation details, start with the grounded Gemma briefing, the guided workflow, and the architecture documentation in the README.

How I Built It

1. Represent the relationships before asking for recommendations

The factory is represented in FalkorDB through connected operational entities: machines, jobs, operators, materials and customer orders.

Those relationships let the application follow a disruption beyond its immediate location.

A machine failure affects a production stage. That stage may block another stage. Those stages contribute to a customer order.

This makes the impact inspectable. An operator can follow the path behind an affected order instead of accepting an unexplained warning.

Caption: The affected customer order is connected to the failed machine through recorded production dependencies.

2. Keep scheduling and money in deterministic code

I wanted the AI boundary to be clear.

The planner checks machine suitability, operator qualifications, existing bookings, shifts, permitted overtime, dependencies and material readiness.

The financial calculation uses configured rates for components such as equipment downtime, waiting labour, changeovers, repair labour and order delay penalties.

Money is stored as integer paise.

This also exposes trade-offs that an optimistic summary could miss. Moving production elsewhere may protect a deadline, but it does not erase the broken machine’s downtime cost. A changeover can add cost even when the overall recovery is preferable.

The planner is bounded and designed around small modeled factories. It does not claim industrial-scale optimal scheduling.

3. Give Gemma a useful, restricted responsibility

FactoryGraph uses Gemma 3 4B locally through Ollama for the recovery briefing.

Its responsibility is to help a beginner notice the important facts in an already calculated proposal.

The application prepares a set of supported facts. Gemma selects identifiers for the summary, trade-offs and review checks. The server validates those identifiers and renders the corresponding text.

That means the recovery briefing cannot introduce an invented rupee amount or a new machine assignment.

The application also always includes the cost comparison and the reminder that approval belongs to the operator. Those essential details do not depend on the model remembering to mention them.

Caption: Gemma selects relevant points from calculated evidence. It has no production mutation or approval tools.

4. Treat model failure as an expected condition

During development, the briefing sometimes showed a rule-based fallback. That was a useful reminder that connecting a model is only part of the job.

A local model can be unavailable, take too long to load, or return an unsupported response.

The briefing now uses a constrained selection schema, validates its output, and distinguishes failure reasons such as an unreachable service, missing model, timeout or invalid response.

If generation fails, the application identifies the fallback and keeps the recovery workflow available.

I would rather show an honest, limited explanation than make a model’s availability a requirement for reviewing a calculated plan.

5. Approve the exact proposal that was reviewed

A recommendation is useful only if the approval refers to the same recommendation.

The server creates a canonical hash for a proposal. Approval submits that hash, and the application checks ownership, proposal status, revision and current planning context.

If the context changes, the operator must reanalyse rather than apply an old proposal.

Repair completion is separate, too. Recording that a machine is available does not silently move work back. Restoration gets its own review.

How the pieces fit together

Suggested diagram: Browser → FastAPI → FalkorDB and planning logic; FastAPI → Ollama/Gemma for read-only briefings; LangGraph → saved day-based workflow checkpoints.

The browser interface is built with HTML, CSS and JavaScript. FastAPI handles the application endpoints. FalkorDB stores connected factory context and operational records.

LangGraph manages the separate day-based recovery workflow with saved checkpoints. The hourly breakdown workflow shown in the Guide uses its own saved reviews and approval endpoints; it is not simply one long language-model conversation.

What I verified

The latest local verification included 61 passing backend tests, five frontend tests, and a packaged Linux smoke check.

Question	Evidence checked
Can approval apply an altered or outdated proposal?	Tests cover proposal tampering and stale planning context
Can another workspace’s data leak into the Guide?	Frontend checks cover scope boundaries
Does clicking through explanatory screens change production?	Navigation is checked separately from mutation
Can the workflow continue without Gemma?	Briefing failure and deterministic fallback are tested
Does the complete example work through the interface?	Browser walkthrough covers recovery, repair, restoration and memory

These checks establish behavior in the demonstrated environment. They do not establish real-world savings, factory-scale performance or production readiness.

Why Does Open Innovation Matter?

A factory’s order deadlines, operating rates and recovery choices can be sensitive business information.

Running Gemma locally means the briefing does not require sending that factory context to an external model API. After the model and dependencies are installed, the local inference path does not need a hosted inference service.

It also gives me control over the model, schema and failure handling. I can change the briefing behavior without rewriting the scheduling rules or tying the product to one provider’s inference pricing.

There are still costs: hardware, electricity, setup and support. A cold model can also take time to load. Local inference makes those trade-offs mine to manage; it does not make them disappear.

Open-source frameworks matter beyond inference as well. LangGraph provides inspectable workflow machinery, while the surrounding application can preserve explicit boundaries between reading context, proposing work and approving changes.

A hosted API could support a similar design. The advantage here is being able to offer the local deployment model and control that this particular customer might value.

What I would build next

Before adding more AI features, I would prioritise:

A workshop pilot: validate the configuration against actual scheduling habits and recorded breakdowns.
Easier onboarding: import existing machine, order and shift data instead of entering everything manually.
A paid-service foundation: accounts, subscriptions, backups and support tooling once the pilot establishes value.

Live telemetry is another direction, but the current machine-health readings are simulated. I would not describe them as failure prediction.

The next milestone I care about is a workshop supervisor being able to inspect a recovery and say, “Yes, that matches how our floor works.”

Prize Categories

Best Use of Gemma

FactoryGraph runs Gemma 3 4B locally through Ollama to select useful briefing points from calculated factory facts. Its output is validated, its operational permissions are restricted, and the workflow remains available when inference fails.

Building FactoryGraph made me appreciate how much happens between “a machine stopped” and “we know what to do.”

The schedule, the dependencies, the customer promise, the cost assumptions and the repair history all have to meet somewhere.

That is the product I want to keep building: a place where a small workshop can bring those facts together and make its next decision with more confidence.

I Built a Pokédex for My Neighbourhood - Because “Go Outside” Needed Better Instructions

Sarvesh — Sun, 11 Oct 2026 18:29:49 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

“Okay, I should go outside.”

Then comes the surprisingly difficult follow-up:

And do what?

Sometimes the problem isn’t that going outside sounds bad. It’s that staying home already has a plan. Open an app. Scroll. Watch something. Somehow, an hour disappears.

Outside has possibilities, but no obvious starting point.

I wanted to make that starting point a little more interesting.

So I built NeighbourDex, a web app that turns a neighbourhood into a small, collectible adventure. Think Pokédex, except your next discovery might be a snack, a park, a landmark, or an interesting texture on a wall.

The collection fills up with photographs you take while exploring.

A smaller adventure felt like a better adventure

My first idea was to generate a guide for an entire city.

But “explore Tokyo” is a big assignment. “Find something interesting around Shibuya” feels like something you could actually do this afternoon.

That became the scope: pick a neighbourhood, get a manageable collection, and choose one thing to try.

After creating an account, you can add multiple neighbourhood adventures. Enter the locality and city, confirm the suggested starting point, and choose a three- or five-kilometre search radius.

A standard collection contains 10–12 cards, covering food, landmarks, nature, and two discovery prompts. If the area has fewer suitable results, you can explicitly allow a smaller guide.

No imaginary park gets added just to make the numbers look good.

Your neighbourhood gets side quests

Each card gives you a small mission, an estimated duration, and instructions about what to photograph.

You might photograph food or a drink at a nearby spot, look for greenery in a park, or capture a recognizable feature of a landmark. The discovery cards ask you to notice things such as surface textures and the sky.

Those last two matter to me. Exploring shouldn’t always require buying something or finding a famous attraction. Sometimes a worthwhile discovery is already on the street you walk down every day.

You can filter the cards by category or collection status, switch to a map, open a numbered pin, check a place’s source, and get directions.

Pick a quest. Put the screen away. Give the neighbourhood a chance.

The reward is a memory you made

When you take or upload a photo, Gemma reviews the visible evidence against the card’s requirements.

A matching photo unlocks the card and becomes its artwork. You can add a short memory note, and your progress earns explorer stamps.

An uncertain or unrelated photo leaves the card undiscovered, with feedback so you can try again.

There’s an important boundary here: a photograph can show food, greenery, or a recognizable landmark. It cannot reliably prove where you were or when you visited. NeighbourDex treats this as a playful collection, rather than a location-verification system.
Once you have collected a few cards, you can create a postcard: choose up to four photographs, optionally include your username, preview it, and download the image.Nothing gets posted automatically. You decide which memories leave the app.

Demo

youtube demo video

The demo follows the complete journey:

Create an account → add a neighbourhood → generate a guide → explore a card → submit a photo → collect it → make a postcard.

The current version runs locally, with Ollama running on the same computer.

Code

github

The project includes an MIT license and setup instructions in the README.

To run it locally, you need Node.js 24 or later, a SerpApi key, and Ollama with gemma3:4b installed.

npm install
ollama pull gemma3:4b
npm run dev

Configure the SerpApi key in the server’s .env file, keep Ollama running, and open http://localhost:3000.

How I Built It

I used a small stack: HTML, CSS, JavaScript, Node.js, SQLite, SerpApi, and Gemma 3 4B through Ollama. Leaflet provides the map interface, and Sharp processes uploaded images.

The interface has a field-guide feel: numbered entries, soft colours, category badges, and photographs that gradually replace the empty card artwork.

I wanted opening the app to feel like unfolding a little adventure booklet.

The architecture

There are two main paths through the app:

Create an adventure
Browser → Node.js → SerpApi place searches
                  → Filter nearby places
                  → Local Gemma writes titles
                  → SQLite saves the collection

Collect a card
Photo → Node.js → Normalize image
               → Local Gemma observes and compares
               → Save review and collection progress

SerpApi supplies the place data. Its Google Maps results help resolve the neighbourhood and find nearby food spots, landmarks, and nature locations. The server removes duplicates, excludes places outside the chosen radius, and retains source links and coordinates.

Gemma supplies the language and visual review. During generation, it writes playful titles for the sourced entries. During photo review, it first describes the image without seeing the quest, then compares those observations with the required evidence.

The application code sets the rules. Place identities, missions, evidence requirements, and collection updates are controlled and validated by the server.

SQLite stores accounts, sessions, collections, notes, reviews, caches, and queued jobs. Photos stay in private server storage and are available only to their owning account.

Why Does Open Innovation Matter?

For NeighbourDex, running an open-weight model locally changed what I could experiment with.

I could adjust prompts, test bad outputs, and refine the photo-review flow without paying for every model request. Uploaded photos go to my configured local Ollama instance rather than a hosted AI service. It also leaves room to change the model. The app defaults to gemma3:4b, but the inference configuration can point to another compatible model as the hardware or project evolves.This doesn’t make the whole application offline. SerpApi searches and map tiles still need internet access. The local model specifically gives me control over the inference step.

My Building Session

I built and refined NeighbourDex with help from AI Tools, working through the account system, place-search pipeline, local inference, photo reviews, and interface improvements.

Prize Categories

I’m entering these categories from the challenge’s category list:

Best Use of Gemma: Local Gemma 3 4B powers quest-title generation and photo-evidence review.
Best Use of SerpApi: Google Maps searches ground the adventures in nearby places, with coordinates and source links.

I started with a simple frustration: wanting to go outside, but having no particular reason to leave.

NeighbourDex gives that moment a small next step.

A place to try. Something to notice. A photograph to keep.

And, hopefully, an afternoon that doesn’t disappear into the scroll. Cheers!

DEV Community: Sarvesh

I Built a Travel Agent That Plans With You and Travels Along Virtually

The family should talk naturally. The system should behave carefully.

Why Switch became the backbone

Six roles, without six agents talking at once

A recommendation needs evidence behind it

Memory should remember who said what

A dependency graph, stored in SQLite

Disruption recovery has an approval boundary

The most useful debugging lesson: good data can still produce a bad experience

Reliability needs more than a convincing reply

Phase 1 is the foundation

I Built an AI Food Scout Because “What Should I Eat?” Is a Surprisingly Hard Question 🍜

What I Built

What makes it different?

The quickest way to understand CraveCode is to see a complete search:

Code

How I Built It

The engineering principle tying it together

Why I Didn't Let AI Decide Everything

What I'd improve next

The Lazy Payoff

Prize Categories

The inspection machine was working. The order was still late. So I built FactoryGraph.

What I Built

Who would pay for this?

Demo

Why I added a Guide

Code

SarveshDujari / FactoryGraph

FactoryGraph

When a machine stops, understand the impact before making the next move.

Contents

The problem

How I Built It

1. Represent the relationships before asking for recommendations

2. Keep scheduling and money in deterministic code

3. Give Gemma a useful, restricted responsibility

4. Treat model failure as an expected condition

5. Approve the exact proposal that was reviewed

How the pieces fit together

What I verified

Why Does Open Innovation Matter?

What I would build next

Prize Categories

I Built a Pokédex for My Neighbourhood - Because “Go Outside” Needed Better Instructions

What I Built

A smaller adventure felt like a better adventure

Your neighbourhood gets side quests

The reward is a memory you made

Demo

Code

How I Built It

The architecture

Why Does Open Innovation Matter?

My Building Session

Prize Categories