DEV Community: Shruti Hiraman Kotgire

The 404 Wasn't the End. I Built an AI Investigator for the Internet's Ghosts.

Shruti Hiraman Kotgire — Fri, 30 Oct 2026 23:53:07 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

A documentation link breaks.

You try it again. Still broken.

Maybe the page moved. Maybe the project was abandoned. Maybe someone deleted years of useful explanations without leaving a forwarding address.

But what if the page isn't completely gone?

What if a copy is still hiding somewhere in the history of the internet?

That's the question behind Afterlink.

What I Built

Afterlink is an AI-powered documentation investigation tool. It searches for historical versions of broken or changed documentation links, retrieves archived content, and uses AI to help investigate what those pages contained.

I interpreted Ghost in the Machine as the forgotten parts of the internet: documentation that disappears, tutorials that become inaccessible, and technical knowledge that survives only in old snapshots.

I wanted to build something that could investigate those digital traces rather than simply announce that a link was broken.

Here's the investigation process:

Upload a Markdown or text document.
Afterlink extracts the documentation links.
It checks which links are accessible, redirected, or unavailable.
It searches the Internet Archive for historical captures.
It retrieves archived pages and extracts readable content.
AI examines the supplied historical evidence and generates investigation recommendations.
It shows the evidence behind its recommendation.
The application compares original and archived content and lets you save or export the investigation.
It lets you save the investigation and export the results.

The important part is what Afterlink doesn't do.

It doesn't silently replace your broken link.

It doesn't pretend that an AI-generated answer is historical truth.

It doesn't commit changes to your repository.

Instead, it gives you evidence and lets you decide what should be recovered.

Afterlink doesn't resurrect documentation by guessing. It investigates what the archive remembers.

That is my interpretation of the Ghost in the Machine theme: the "ghost" is forgotten documentation still haunting the links inside today's codebase.

The key design decision: AI must investigate evidence, not invent history.

A model can produce a convincing explanation of a missing page without actually knowing what it contained. Afterlink validates recommendation URLs and evidence excerpts against the supplied archive information before displaying them.

It also preserves the distinction between an unavailable page, an archived page, and a conclusion supported by historical evidence.

Demo

Try Afterlink: https://afterlink-sigma.vercel.app/

Source code: https://github.com/shrutikotgire0129/afterlink

The application is deployed on Vercel. You can load the sample project and run an investigation without installing Ollama.

Screenshots

The investigation workspace

Investigation results

Original versus archived content

Investigation history

Code

Repository: https://github.com/shrutikotgire0129/afterlink

Tech stack:

Next.js 16
React
TypeScript
Tailwind CSS
Ollama
Gemma 3 1B
Groq API
GPT-OSS 20B
Internet Archive

The main investigation pipeline:

Document
   |
   v
Link Extraction
   |
   v
Link Availability Checks
   |
   v
Internet Archive CDX Search
   |
   v
Archived Page Retrieval
   |
   v
Content Extraction
   |
   v
AI Investigation
   |
   v
Evidence Validation
   |
   v
Original / Archive Comparison
   |
   v
Investigation Report

Each stage has its own API route. That separation makes it easier to validate inputs, handle failures, and prevent an error in one stage from silently becoming an incorrect investigation result.

How I Built It

1. The open-weight model is part of the actual workflow

I wanted Afterlink to support local AI inference rather than depend entirely on a hosted model.

For local development, I integrated:

Ollama as the local inference runtime.
Gemma 3 1B as the local model.

The application communicates with Ollama through its local API:

http://localhost:11434/api/chat

This made it possible to develop and run the AI investigation workflow on my own machine without requiring a paid hosted AI API for local inference.

2. A different inference provider for the public demo

I also wanted anyone to be able to try Afterlink without installing a model locally.

The deployed Vercel application therefore uses Groq with the open-weight openai/gpt-oss-20b model.

Environment	AI runtime	Model
Local development	Ollama	Gemma 3 1B
Production deployment	Groq	GPT-OSS 20B

The provider is selected server-side based on the execution environment. The Groq API key is stored as a server-side environment variable.

I tested an important deployment scenario: I stopped Ollama on my computer and ran the complete AI investigation workflow on the deployed Vercel application. It continued working.

The production application does not depend on my computer being switched on.

3. The difficult part: preventing convincing but unsupported answers

An AI model can return a plausible archive recommendation that doesn't actually match the historical capture supplied to it.

During development, I encountered an issue where matching candidates using only the original page URL was insufficient when multiple archive snapshots existed.

I tightened the matching logic so that both the original candidate URL and the exact archive URL must match.

I also added validation for evidence excerpts. An excerpt must be present in the supplied archived content; the model cannot simply invent a quotation and present it as evidence.

Other reliability measures include:

Request and URL validation.
Response-size limits.
Timeouts for external requests and model inference.
Validation of incomplete or malformed AI responses.
Error handling when Ollama or the hosted AI provider is unavailable.
Clear distinction between unavailable archive content and evidence that a page never existed.

I deliberately prefer an uncertain result over an unsupported conclusion.

4. The investigation doesn't end with the AI response

Afterlink also supports:

Original-versus-archive content comparison.
Markdown investigation reports.
JSON export.
Investigation history with restore and delete functionality.

The result is intended to be useful beyond a single AI response.

Why Does Open Innovation Matter?

The open part of Afterlink changes how the investigation system can be run and adapted.

Local inference: Gemma 3 1B can run through Ollama on a developer's own machine. Local analysis doesn't require sending the AI prompt to a hosted model provider.

Model flexibility: The investigation workflow is separated from the model provider. I can use Gemma locally and a different open-weight model in production without redesigning the entire application.

Control and experimentation: Running an open-weight model locally makes it possible to inspect its behavior, change prompts, test limitations, and improve evidence validation around its actual outputs.

Accessibility: A small model makes local experimentation possible on modest hardware, although inference speed and available memory still depend on the machine.

There is an important limitation: retrieving historical pages still requires internet access, and the public Vercel demo uses hosted inference. Afterlink is not an entirely offline archive crawler.

For me, open innovation made the project more flexible: I could develop locally, experiment with an open-weight model, and make the application accessible through a hosted deployment.

The Spirit of It

A 404 page is a strange kind of disappearance.

The address is still there. The link is still in someone's notes, tutorial, or README. But the information behind it has vanished.

Sometimes an old snapshot survives.

Maybe it contains the explanation someone needs. Maybe it only contains part of the page. Maybe it provides no useful evidence at all.

Afterlink cannot bring every missing page back. It can, however, investigate what remains and make that evidence easier to understand.

I built it around one idea:

The internet forgets. The archive remembers. Afterlink investigates.

What I Learned

The biggest lesson from building Afterlink was that AI is often most useful when it is not allowed to do everything.

The strongest parts of the application are the boundaries around the model:

deterministic link extraction
explicit archive retrieval
bounded content extraction
evidence validation
original-versus-archive comparison
human review
visible uncertainty

The model handles the ambiguous part.

Code handles the parts that should be predictable.

That separation made the project much more reliable.

Prize Categories

Best Use of Gemma: The local inference workflow uses Google's Gemma 3 1B model through Ollama. The deployed application uses GPT-OSS 20B through Groq, which is a separate production inference path.

Final Thought

Documentation disappears quietly.

Usually there is no warning.

No final message.

No tombstone.

Just a link that suddenly returns 404.

But the code that depended on that documentation can survive for years.

So I built Afterlink around one question:

When the documentation is gone, what evidence is still alive?

The docs disappeared.
The code remembered.
Afterlink goes looking for what remains.

Built for Ghost in the Machine

Thank you for taking a look at Afterlink — and happy Hacktoberfest. 👻

What Happens When AI Reads Your Receipt but Doesn’t Know Your Return Policy?

Shruti Hiraman Kotgire — Sat, 24 Oct 2026 04:20:43 +0000

You buy something, put the receipt somewhere safe, and tell yourself you’ll remember the return window.

A few weeks later, you find the receipt. The deadline? Already gone. Or maybe you can’t even remember when it was supposed to be.

That everyday problem inspired ReturnRadar, a receipt-powered purchase tracker I built for the DEV Challenge.

The initial idea was straightforward: upload a receipt, extract the important details, and track return deadlines. But while building it, I realized that reading a receipt wasn't the hardest part.

The real challenge was deciding what the application should do when the receipt was blurry, the purchase date was missing, or the return policy wasn't clear.

I didn't want an AI-generated date to look trustworthy just because it appeared in a polished interface.

So I built ReturnRadar around one principle: when the evidence isn't clear, the application should say so instead of guessing.

What is ReturnRadar?

ReturnRadar helps people organize purchases and keep track of return deadlines without relying on memory.

Try the live app: https://return-radar-ruby.vercel.app/

Explore the code: https://github.com/shrutikotgire0129/ReturnRadar

Alternative deployment: https://returnradar-0ftg.onrender.com/

Users can upload receipt images or PDFs, extract purchase information with AI, review and edit the extracted details, manage purchase records, and track upcoming or expired return windows.

The application also supports Google Calendar export for return deadlines—but only after the user has reviewed and explicitly verified the deadline.

Here's what the dashboard looks like:

The dashboard brings purchase records and return statuses together so users can keep track of their deadlines.

The problem I wanted to solve: AI can be confidently wrong

Imagine uploading a receipt that clearly shows the merchant and total price but contains no return policy.

Or imagine a receipt with a blurry purchase date. Perhaps the policy mentions a return period, but the available information doesn't establish exactly when the deadline falls.

An AI model might still return a plausible date. The result could look complete, even when the underlying evidence doesn't support it.

For a return-deadline tracker, that isn't a harmless mistake. Someone could rely on an invented date, miss the actual return window, and lose the opportunity to get a refund.

I wanted the application to distinguish between information it could extract and information that still needed human review.

That led to a simple rule:

Extract what the evidence supports. Flag what it doesn't. Never treat a guess as a verified deadline.

How I used an open-weight vision model

For receipt extraction, ReturnRadar uses Qwen3.8-27B through the Groq API.

The model processes the uploaded receipt and returns structured information, including:

Merchant and item name
Purchase date and total price
Return window and return-by date, when supported by the available information
Warranty information, when available
Receipt or policy evidence
Confidence information, warnings, and review requirements

The flow is straightforward: the user uploads a receipt, a Next.js API route sends it for processing through Groq, and the application handles the model's response before presenting the extracted information in the interface.

I chose a vision-capable model because receipts aren't neatly structured database records. They're documents with different layouts, small text, inconsistent formatting, and sometimes poor image quality.

Using an open-weight model also gives the project flexibility to explore different model and deployment options as it evolves.

There is an important distinction, though: ReturnRadar currently uses hosted inference through Groq. Qwen does not run locally in this version of the application.

The model's open weights make different deployment arrangements possible to explore, but using an open-weight model doesn't automatically mean the application runs privately on the user's device.

Here's the receipt upload interface:

Users upload a receipt to extract purchase details that they can review before relying on them.

Turning AI output into a safer user experience

Getting structured output from a model is only one part of the problem. The application also needs rules for deciding what users can do with that output.

I focused on four areas.

1. Keep evidence visible

ReturnRadar keeps receipt evidence, return-policy evidence, and extraction warnings alongside purchase details.

This gives users context for reviewing the result instead of asking them to trust a date without knowing where it came from.

2. Flag incomplete or uncertain records

When important information is missing, a return policy cannot be established, or an extraction needs further review, the purchase can be marked Needs review.

The interface doesn't have to pretend every receipt was processed successfully. Sometimes the most useful result is an honest warning that the available information isn't enough.

3. Separate extraction from verification

An extracted date is not automatically treated as a verified deadline.

The user must confirm that they checked the retailer's actual return policy. This confirmation records the user's action; it does not mean the application independently contacted the retailer or verified the policy itself.

That distinction matters because extracting a date and establishing that the date is correct are two different tasks.

4. Prevent calendar export for unsupported deadlines

ReturnRadar requires the relevant receipt evidence and a deadline marked as verified before allowing Google Calendar export.

If those requirements aren't met, the application blocks the action and explains why.

A reminder based on an unsupported date could be worse than no reminder at all. It might give someone false confidence that they still have time to return a product.

Here's the purchase details view:

The purchase details view gives users a place to inspect extracted information and its review status.

What else I built

ReturnRadar is built with Next.js, React, and TypeScript. Purchase records are persisted in the browser using local storage.

The current version includes:

A dashboard for purchase records and return statuses
Receipt uploads for supported image and PDF formats
AI-assisted extraction with editable fields
Search and filtering for purchases
Persistent purchase records across page refreshes
Purchase status management
Evidence, warnings, and review states
Google Calendar export for eligible, verified deadlines

I also tested scenarios beyond a clean, readable receipt: blurry images, missing purchase dates, unclear amounts, and ambiguous return policies.

I checked that uncertain information could be flagged for review, that corrections persisted after refreshing, and that calendar export remained blocked when the deadline wasn't sufficiently supported or verified.

The goal wasn't to make every receipt appear successful. It was to make the application behave responsibly when the available information was incomplete.

What I learned about building with open AI

This project reinforced a lesson I'll carry into future AI applications:

A model's answer should not automatically become the application's truth.

A model can extract information, but the surrounding software still needs to decide what actions are appropriate based on that information.

For ReturnRadar, that meant separating extraction from verification, keeping evidence attached to results, and preventing calendar export when a deadline hadn't been confirmed.

Open-weight models make it possible to experiment with model selection and explore different deployment strategies. But openness alone doesn't guarantee privacy, accuracy, or safety. Those properties also depend on the inference provider, data handling, validation, and the decisions made in the application itself.

There is also a privacy consideration in the current implementation: because ReturnRadar uses Groq-hosted inference, uploaded receipt content is sent to that external service for processing. Purchase records are stored in the browser, but receipt processing does not happen entirely on the user's device.

A future version with local inference would be worth exploring for users who want receipt processing to remain on their own hardware.

Try it and share feedback

If you have a few minutes, try the live application or explore the repository.

I'd especially appreciate feedback on the receipt-review experience, the way uncertainty is communicated, and what would make you comfortable relying on an AI-assisted tool for something as practical as a return deadline.

ScopeGuard AI: An Open-Weight AI Assistant That Helps Freelancers Protect Their Scope of Work

Shruti Hiraman Kotgire — Fri, 16 Oct 2026 23:57:59 +0000

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

A project begins with a clear agreement, a defined price, and a shared understanding of what needs to be delivered.

Then the messages start arriving.

“Could you add one more dashboard?”

“Can we include subscription billing, too?”

“It should be a small change, right?”

For freelancers, these requests can create an uncomfortable choice: absorb the extra work to keep the client happy, or explain why the request may fall outside the original agreement.

The difficult part is not always saying no. It is figuring out what was actually agreed upon, whether the new request fits within that agreement, and how to communicate the answer professionally.

That is the problem I built ScopeGuard AI to help solve.

What I Built

ScopeGuard AI is an AI-powered scope analysis assistant designed for freelancers and independent developers who want to manage client expectations and protect their time.

It compares a client's new request against the original project agreement and helps the freelancer understand whether the requested work appears to be included, potentially out of scope, or in need of clarification.

Instead of returning only a classification, it provides supporting agreement evidence, an explanation, and a recommended next action.

How does it work?

The workflow is straightforward:

Provide the original agreement. Enter the agreed project requirements and deliverables.
Add the new client request. Describe the additional feature, revision, or change being requested.
Analyze the scope. The AI compares the request with the agreement and returns one of three outcomes:
- Included: The agreement supports treating the request as part of the existing scope.
- Potentially out of scope: The request appears to go beyond the agreed deliverables.
- Needs clarification: The available information is insufficient for a confident determination.
Review the evidence. Examine the relevant agreement excerpts and the AI's interpretation of them.
Take action. Generate a professional client reply or prepare a change-order proposal for additional work.

The change-order generator calculates a proposed fee using the estimated additional hours and the freelancer's hourly rate. The freelancer can then review the proposal before using it with the client.

The goal is not to label every new request as scope creep. Sometimes the work is already included. Sometimes the agreement is ambiguous. Sometimes the client is asking for a legitimate addition that deserves a separate estimate.

The goal is to help freelancers make that distinction before committing to more work.

Who would pay for it?

My initial target customers are freelancers and independent developers who manage projects directly with clients, especially those building websites and software.

For these professionals, unexpected work can affect profitability, delivery schedules, and client relationships. ScopeGuard AI is designed to make scope discussions easier by turning an unclear situation into an evidence-backed analysis and a practical next step.

A potential business model is a freemium product: occasional analyses could be available on a free tier, while paid plans could offer higher usage limits and additional project-management capabilities.

This is a proposed monetization strategy, not a claim that the product already has paying customers. My next goal is to validate whether freelancers find the workflow valuable enough to pay for it.

Demo

Try ScopeGuard AI yourself or watch the video demonstration.

Live demo — Vercel: https://scope-guard-ai-wine.vercel.app/
Alternative deployment — Render: https://scopeguard-ai.onrender.com/
Video demo: https://youtu.be/QE8Jhd25Q34

The application includes a demo scenario involving a business website, additional revisions, an admin dashboard, and subscription billing.

The live application lets you explore the workflow, while the video provides another way to see the project in action.

Code

The source code is available on GitHub:

Explore the ScopeGuard AI repository

The repository contains the application code and setup instructions for developers who want to explore the implementation.

How I Built It

I wanted to build more than a chatbot that answers whether a request sounds like scope creep. The important part was connecting the AI's analysis to the actual agreement and making the output useful for a freelancer's next decision.

1. Open-weight AI at the core

ScopeGuard AI uses OpenAI's gpt-oss-20b open-weight model through Groq's hosted inference API.

The application sends the original agreement and the client's new request to the model. The model produces a structured analysis containing the scope status, reasoning, agreement evidence, and recommended action.

The application then presents that result through a task-specific interface rather than exposing the user to a raw model response.

The model runs through hosted inference in the current version; it is not running locally on the user's machine.

2. Evidence instead of a bare AI verdict

A freelancer needs to explain a scope decision, not merely receive a label.

That is why ScopeGuard AI includes relevant agreement excerpts and an interpretation of how they relate to the new request.

This makes the result more useful for reviewing the decision and preparing a client conversation. It also gives the freelancer an opportunity to check whether the model's reasoning makes sense.

The three possible outcomes are intentional. An unclear agreement should not automatically be treated as proof that a request is out of scope.

AI can assist with interpretation, but it cannot guarantee that an assessment is correct or replace professional legal advice. The freelancer remains responsible for reviewing the agreement, evidence, and suggested response.

3. From analysis to action

The application supports a practical workflow beyond the initial classification:

Scope analysis: Compare the client request against the original agreement.
Evidence review: Inspect relevant agreement text and the model's interpretation.
Client communication: Generate a professional reply based on the analysis.
Change-order preparation: Draft a proposal for additional work.
Fee calculation: Calculate a proposed fee from estimated hours and the hourly rate.
History: Revisit saved analyses through browser storage and authenticated cloud history.

These features connect the AI analysis to the decisions freelancers need to make in real client projects.

4. The technology stack

The project combines the following technologies:

Next.js and TypeScript — application framework, UI, and server-side API routes.
Tailwind CSS — responsive interface styling.
Groq and gpt-oss-20b — hosted inference for AI-powered scope analysis.
Clerk — user authentication.
MongoDB Atlas — persistent history storage.
Browser local storage — local history.
Vercel and Render — application deployments.

I also built a demo scenario to make the project easier to evaluate without requiring every visitor to prepare their own agreement and client request.

5. Building for a real workflow

One of the key design decisions was to keep the analysis connected to what the user can do next.

A scope classification on its own is not enough. Freelancers also need to explain the decision, respond to the client, and estimate the cost of additional work.

ScopeGuard AI brings those steps together in one interface.

The current implementation is a working prototype. Its next stage should involve testing with real freelancers, collecting feedback, and evaluating the model against a representative set of agreements and change requests.

Why Does Open Innovation Matter?

For ScopeGuard AI, open innovation is about flexibility, experimentation, and the ability to build around a model that is not limited to a single closed-model ecosystem.

Using an open-weight model gives the project a model choice that can be evaluated, replaced, or potentially self-hosted in a future version, subject to the model's license and deployment requirements.

That flexibility matters for a product that may handle sensitive business information, such as client agreements, project requirements, and pricing discussions.

There is an important distinction in the current implementation: ScopeGuard AI uses hosted inference through Groq. It does not currently run the model locally or guarantee that agreement text stays entirely on the user's device.

A future self-hosted deployment could provide a different level of infrastructure control, but that is a possibility for future development, not a feature I am claiming today.

Open-weight models also make it possible to experiment with alternatives and evaluate how well they handle the specific challenges of scope analysis:

Can the model identify the agreement language relevant to a new request?
Can it distinguish a clearly additional feature from an ambiguous requirement?
Can it explain its reasoning in a way a freelancer can review?
Can it recommend a useful next step without treating every change as an extra charge?

Those are the questions that matter for this product. The ability to evaluate and potentially change the underlying model gives the project room to improve as those questions are tested.

For a small product with a potential paid use case, that flexibility is valuable. It lets development focus on the user's actual problem instead of assuming that one model or provider will always be the right fit.

My Agent Session

I have not included an agent-session recording in this submission. If I create a session using DevRelay, I can add the resulting link here to show the development process.

My First User

I am currently looking to validate ScopeGuard AI with freelancers who regularly handle client projects.

I do not yet have a verified paying-customer story to share, so I would rather be transparent than present hypothetical feedback as a real testimonial.

The next milestone is to put the tool in front of potential users, understand how they currently handle scope changes, and learn whether evidence-backed analysis and change-order preparation solve a problem they would pay to address.

Prize Categories

I am entering the following partner categories:

Best Use of Render: ScopeGuard AI is deployed as a hosted web application on Render.
Best Use of MongoDB Atlas: MongoDB Atlas provides persistent storage for users' saved analysis history alongside the open-weight AI workflow.

Thank you for checking out ScopeGuard AI.

If you work as a freelancer or independent developer, I would be interested in your perspective: When a client asks for something that was never clearly agreed upon, how do you decide whether it belongs in the original scope?

That question is at the heart of ScopeGuard AI, and feedback from people who experience this problem is the most useful next step in making the project better.

[Boost]

Shruti Hiraman Kotgire — Fri, 09 Oct 2026 22:59:50 +0000

Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass Submission 🌿

Shruti Hiraman Kotgire

Oct 9

TrailMate AI

#devchallenge #hf26challenge

5 min read

TrailMate AI

Shruti Hiraman Kotgire — Fri, 09 Oct 2026 22:48:31 +0000

TrailMate AI: I Built an AI That Turns Screen Time Into Outdoor Adventures

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

What I Built

TrailMate AI is an AI-powered outdoor companion that turns your interests, available time, and preferred activities into personalized outdoor missions.

We spend a lot of time looking at screens—even when we want to take a break. Sometimes, the hardest part of going outside is deciding what to do.

Go for a walk? Explore somewhere new? Take nature photographs? Spend an hour noticing things you usually overlook?

I built TrailMate AI to make that decision easier.

Instead of recommending another app to spend time in, TrailMate AI uses Google's open-weight Gemma model to help people discover things to do away from their screens.

How it works

Tell TrailMate what you want. Enter your interests, choose an activity, and select how much time you have.
Get a personalized mission. Gemma generates creative mission content tailored to your request, including a title, a reason the mission fits your preferences, and three activity steps.
Head outside. Follow the mission, complete its steps, and try the nature challenge.
Put your phone away. Start Phone-Free Mode to encourage a more intentional outdoor experience.
Reflect on your progress. Complete your mission, earn a mission score, and revisit your saved mission history.

Activities include walking, hiking, cycling, nature exploration, photography, and a surprise-me option. Missions can be tailored to different time commitments, from one hour to longer adventures.

Features

Personalized AI missions: Turn an idea or interest into an actionable outdoor adventure.
Why this mission?: Understand how the generated mission matches your request, activity, and available time.
Phone-Free Mode: Encourage yourself to stop checking your phone and focus on the experience.
Mission completion score: Track progress through completed steps and mission milestones.
Mission history: Review previous missions and see your accumulated outdoor and phone-free time.
Responsive interface: Plan a mission before leaving and keep the experience simple while outdoors.

The goal isn't to maximize engagement with TrailMate AI. It's to help people use it, make a plan, and then leave their screens behind.

Demo

Try TrailMate AI: https://trailmate-98rtn7ttl-shruti-s-angels.vercel.app/

Here are some screenshots of the application.

Home

Generated outdoor mission

Powered by Gemma

Mission history

Code

GitHub repository: https://github.com/shrutikotgire0129/Trailmate_AI

Live application: https://trailmate-ai.vercel.app/

The repository includes the application source code, AI mission-generation endpoint, mission types, interface, and mission-history implementation.

I'd welcome feedback, suggestions, and contributions that make TrailMate AI more useful, reliable, and effective at encouraging people to spend time outdoors.

How I Built It

I built TrailMate AI with Next.js, React, TypeScript, Tailwind CSS, and Google's open-weight Gemma model.

The project uses the gemma-4-26b-a4b-it model through Google's Gen AI SDK.

Technology stack

Next.js App Router: Application structure and server-side API endpoint.
React and TypeScript: Interactive UI, state management, and typed mission data.
Tailwind CSS: Responsive styling and visual design.
Gemma: Creative generation of personalized mission content.
Browser local storage: Persistence of mission history and user progress without requiring a separate database.
Vercel: Deployment of the application.

Why I didn't let the model generate everything

One of the biggest engineering lessons from this project was that asking an LLM to generate an entire deeply nested object can introduce unnecessary reliability problems.

My initial approach asked the model to produce the complete mission structure, including nested steps, durations, preparation, and safety information. That made the output harder to validate and more susceptible to malformed or inconsistent responses.

I changed the architecture.

Gemma generates the creative content; application code controls the structure.

The model generates a constrained set of short text fields, such as the mission title, explanation, summary, step descriptions, nature challenge, and phone-free tip. The application validates the generated content and constructs the final typed mission object.

The application determines structured fields such as step durations, difficulty, preparation guidance, and safety tips instead of relying on the model to generate every field correctly.

This separation makes the output more predictable and easier to maintain.

The generation flow is:

User preferences → Gemma generation → Output validation → Application-controlled mission construction → Outdoor mission

I also added validation and a limited retry mechanism to handle unsuitable or malformed model output.

Building for the actual goal

The AI generation is only one part of the product. I wanted the interface to encourage an action in the physical world rather than keep users interacting with the application.

That influenced several decisions:

Missions have concrete steps instead of vague motivational suggestions.
Phone-Free Mode encourages users to put their devices away.
Completion tracking provides a clear endpoint to the experience.
Mission history records progress locally.
The mission score rewards completing the activity rather than spending more time in the app.

The application is designed around a simple principle: the best outcome is not more time on TrailMate AI; it is more meaningful time outdoors.

Why Does Open Innovation Matter?

Open innovation matters because AI should be useful beyond products designed to maximize screen time.

Using an open-weight model like Gemma gave this project a model choice that I could build around, experiment with, and integrate into a specific use case. Instead of treating AI as a generic chatbot, I could focus it on generating practical, personalized outdoor experiences.

It also encouraged me to think more carefully about the boundary between model-generated content and application-controlled logic.

The model handles creative personalization. The application handles validation, structure, and predictable behavior.

That separation is important when building AI products that people may use to make real-world plans. Generated suggestions should be helpful, but the application still needs to enforce sensible constraints and provide safety guidance.

Open-weight models also make experimentation more accessible to developers who want to explore AI-powered products and contribute to the ecosystem. They provide another path for building specialized applications without making every product decision depend on a single closed model API.

For TrailMate AI, Gemma makes the experience personal. The rest of the application turns that generated content into a structured mission that someone can actually follow.

Prize Categories

Best Use of Gemma — TrailMate AI uses Gemma as its core creative engine to personalize outdoor missions and support the project's screen-time-reduction goal.

Thanks for checking out TrailMate AI! I built this project for the Hacktoberfest Open-Source AI Challenge, and I hope it inspires more applications that use AI to help people do meaningful things beyond their screens.