DEV Community: PRAVIN KUMAR

GhostGPT: Building a Local AI Horror Story Generator with Ollama

PRAVIN KUMAR — Mon, 26 Oct 2026 22:59:03 +0000

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

What I Built

I built GhostGPT, a local AI-powered horror story generator inspired by the “Ghost in the Machine” theme.

GhostGPT uses Python, Flask, Ollama, and the open-weight Gemma 3 1B model to generate spooky stories locally on your machine. Users can choose horror categories, generate stories, copy their favorite stories, and save them for later.

My goal was to explore how AI can create mysterious and chilling stories while running locally, without depending on a cloud-based AI API for story generation.

Demo

🎬 Watch the GhostGPT Demo Video: Watch on Google Drive

GitHub Repository: https://github.com/PRAVIN-KUMAR-295/GhostGPT

GhostGPT is a local AI-powered horror story generator built with Python, Flask, Ollama, and Gemma 3 1B.

Code

👨‍💻 GitHub Repository: GhostGPT — View Source Code

GhostGPT is built using the following technologies:

Python & Flask — Backend application
Ollama — Local AI model inference
Gemma 3 1B — Open-weight language model for horror story generation
HTML, CSS & JavaScript — Frontend interface

Explore the repository to find the source code and instructions for running GhostGPT locally.

How I Built It

Why Does Open Innovation Matter?

My Agent Session

The Spirit of It

Prize Categories

issme kiya karna hia

StudySloth AI: Study Less, Understand More with Open-Weight AI 🦥

PRAVIN KUMAR — Tue, 20 Oct 2026 10:52:25 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

I built StudySloth AI, a study assistant designed to make revision easier and less time-consuming.

Students often have long notes to review before an exam. StudySloth AI helps turn those notes into concise summaries, extract important key points, and generate interactive quizzes for practice.

The goal is simple: spend less time organizing study material and more time understanding it.

Demo

Video demo: [https://youtu.be/o7pFxF4dSrc?si=fnNZWl_tSDHlAgxq]

The demo shows the app processing study notes, generating a summary, highlighting key points, and creating quiz questions.

Code

GitHub repository: https://github.com/PRAVIN-KUMAR-295/StudySloth-AI

The repository contains the Flask application, frontend, AI integration, setup instructions, and automated tests.

How I Built It

StudySloth AI is built with Python, Flask, HTML, CSS, and JavaScript.

Its primary AI engine uses Google's Gemma open-weight model (gemma-4-26b-a4b-it) through hosted inference. This means users do not need to download a large model or configure a local GPU to use the application.

The app uses the model to generate study summaries, key points, and quiz questions. It also includes an optional proprietary Gemini fallback when the primary model encounters certain failures or rate limits. The interface distinguishes between open-weight inference, fallback mode, and demo mode so users can understand which engine is active.

The project includes input validation and automated tests for its main features.

Why Does Open Innovation Matter?

Open-weight models give developers more flexibility to inspect, evaluate, adapt, and build around model weights under the applicable license.

For StudySloth AI, Gemma makes it possible to build a study assistant without making a proprietary model the only option. Hosted inference also makes the application easier to try on an ordinary laptop without requiring a local GPU or a large model download.

There is an important trade-off: hosted inference requires an internet connection, and submitted notes are sent to the inference provider for processing. This version is not an offline or fully local AI application.

I believe open innovation matters because it gives developers more choice in how AI-powered tools are built and improved.

The Lazy Payoff

Instead of manually condensing every page of notes and writing practice questions from scratch, students can use StudySloth AI to create a starting point for revision in one place.

It is designed to reduce repetitive study preparation, not replace learning. Students should still review generated summaries and verify important facts before an exam.

Prize Categories

This submission is for the overall Hacktoberfest Open-Source AI Challenge Week 3.

I am not claiming entry into any partner prize category.

Thanks for checking out StudySloth AI! 🦥

TRACEFORGE AI: Investigating Microservice Incidents with Graph-Based Reasoning

PRAVIN KUMAR — Sun, 18 Oct 2026 12:59:46 +0000

The Problem

Modern applications often consist of multiple interconnected microservices. When one service fails, the impact can spread through its dependencies and cause cascading errors across the system.

Finding the original cause can require engineers to inspect logs, trace dependencies, and correlate evidence across multiple services. TRACEFORGE AI is my project to make this investigation process more structured and easier to follow.

Introducing TRACEFORGE AI

TRACEFORGE AI is an AI-assisted incident investigation tool designed to help engineers explore service dependencies, investigate cascading failures, and identify potential root causes.

The application brings together a service topology, graph-query exploration, incident investigation context, and recommended remediation actions. Its goal is to help engineers move from an alert toward an evidence-informed hypothesis and a practical next step.

Why Graphs?

Microservice architectures naturally contain relationships: an API gateway communicates with downstream services, checkout depends on payment processing, and authentication components may depend on caches or other infrastructure.

Representing these relationships as a graph makes it possible to explore how services are connected and which dependencies may be relevant to an incident.

TRACEFORGE AI models services as graph nodes and their dependencies as relationships. Cypher-style graph queries can then be used to explore connected services and investigate possible failure propagation.

Where FalkorDB Fits

The backend includes a native FalkorDB client intended for graph-backed operations. FalkorDB is relevant to this project because graph queries provide a natural way to represent service dependencies and traverse relationships during incident investigation.

The project also includes an in-memory Cypher engine as a fallback for environments where a live FalkorDB server is unavailable. At the time of writing, the public deployment uses this fallback, and live FalkorDB connectivity has not yet been verified in the deployed environment. This distinction is important when evaluating the current demo.

Investigation Workflow

The TRACEFORGE AI demo showcases the following workflow:

Incident overview: Review an incident and its reported symptoms.
Service topology: Explore the graph of connected services and their dependencies.
Graph query exploration: Examine dependency relationships using graph-query concepts.
Incident investigation: Organize available evidence and investigation findings into potential root-cause hypotheses.
Remediation recommendations: Present possible next steps while keeping remediation decisions under human control.

The intention is not to replace engineers. It is to provide a more organized starting point for investigating complex incidents.

Challenges and Lessons Learned

One important engineering lesson is that a working application interface does not automatically prove that its intended database is connected and being used by the deployed service.

A graph-backed application needs clear configuration, reliable connection handling, useful fallback behavior, and a way to verify which backend is active. A fallback can keep a demo usable, but it should not be confused with a successful live database connection.

I also learned the importance of making investigation results understandable. Showing service relationships, evidence, hypotheses, and recommended actions helps make an AI-assisted workflow easier for engineers to review.

What's Next?

The next steps for TRACEFORGE AI include verifying live FalkorDB connectivity in a configured environment, strengthening end-to-end tests against the actual graph database, and improving the traceability between graph-query results, incident evidence, and remediation recommendations.

Conclusion

TRACEFORGE AI explores how graph-based dependency analysis can help engineers investigate cascading microservice failures. By combining service relationships with an AI-assisted investigation workflow and human-reviewed recommendations, the project aims to make incident response more structured and understandable.

The project is a work in progress, and verifying the live graph-database path is an important part of making the deployment match the intended architecture.

Local Seller AI: An AI-Powered Marketing Copilot for Small Businesses

PRAVIN KUMAR — Wed, 14 Oct 2026 04:41:23 +0000

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

What I Built

I built Local Seller AI, an AI-powered marketing copilot for small business owners, local shopkeepers, and side hustlers.

It helps sellers create product descriptions, social media captions, WhatsApp promotional messages, and SEO keywords. It also includes a pricing calculator and a 7-day marketing planner.

Small sellers often have limited time and budget for marketing. This tool brings these tasks together in one simple app, helping them save time and organize their business activities.

It is designed for local shopkeepers, home-based businesses, and freelancers who want an affordable way to manage everyday marketing tasks.

Demo

Try Local Seller AI here:

Live Demo: https://local-seller-ai.onrender.com

Explore the marketing content generator, pricing calculator, and 7-day marketing planner.

Code

GitHub Repository: https://github.com/PRAVIN-KUMAR-295/local-seller-ai
The repository includes the Streamlit application, marketing content generator, pricing calculator, 7-day marketing planner, and automated tests.

How I Built It

I built Local Seller AI using Python and Streamlit to create a simple, interactive web application.

The project is organized into separate modules for marketing content generation, pricing calculations, and weekly marketing planning.

For AI-powered content generation, I integrated Hugging Face's InferenceClient with open-weight language models, including Qwen2.5 and Llama 3.2.

The app generates product descriptions, social media captions, WhatsApp promotional messages, and SEO keywords in English, Hindi, and Hinglish. It also includes a Demo Mode so users can explore the features using sample content.

I wrote automated tests for the main features and error-handling scenarios. All 27 automated tests passed.

The deployed app's live AI generation depends on the Hugging Face token, model availability, and inference service. The tests include mocked API responses, so I still need to verify live AI inference separately if it has not already been tested.

Why Does Open Innovation Matter?

Open innovation matters because small businesses need affordable, flexible tools that can adapt to their needs.

By integrating open-weight language models through Hugging Face, Local Seller AI can explore different models instead of depending entirely on a single closed AI provider.

This flexibility is useful for a marketing tool that supports English, Hindi, and Hinglish. Different models can be evaluated for content quality, language support, availability, and inference cost.

Open-weight models also give developers more control over how their AI applications are built and improved over time.

My goal is to make AI-assisted marketing more accessible to small sellers who may not have the budget for a dedicated marketing team.

Currently, the app uses Hugging Face inference integration, so live generation depends on the configured model and inference service. Fully offline operation is not currently claimed.

TouchGrass AI: An Open-Source AI Outdoor Mission Planner

PRAVIN KUMAR — Wed, 07 Oct 2026 20:57:44 +0000

TouchGrass AI: An Open-Source AI Outdoor Mission Planner

What if AI helped you spend less time looking at a screen?

That was the idea behind TouchGrass AI, an outdoor mission planner built for the Hacktoberfest 2026 Open-Source AI Challenge: Week 1.

What I Built

TouchGrass AI creates short, practical outdoor missions based on:

Available time: 15, 30, or 60 minutes
Activity: Walking, Nature, Photography, Exercise, or Social
Difficulty: Easy, Medium, or Hard
Mode: Solo or With Friends

Instead of keeping the user inside the app, the goal is to use the screen briefly, get a mission, and then put the phone away.

For example, a 30-minute nature mission can ask you to walk without looking at a screen, observe different plants, notice a natural sound, and spend a few quiet minutes outside.

The Problem

A lot of digital products are designed to keep us on the screen.

For this challenge, I wanted to build the opposite: an AI experience where the screen is only the starting point.

The useful part of the experience happens outside.

The "Touch Grass" Idea

The core interaction is intentionally simple:

Choose → Generate → Go outside → Complete → Come back

The app gives the user an actionable outdoor objective and encourages them to put their phone away once the mission starts.

This makes the AI a short planning tool rather than another reason to keep scrolling.

How It Works

The user selects their available time.
They choose an outdoor activity.
They choose difficulty and solo/friends mode.
The backend creates a structured mission.
The user starts the mission.
The app provides an actionable checklist.
The user goes outside and completes it.
The completed mission is saved to history and reflected in statistics.

TouchGrass AI also keeps a history of completed missions and shows outdoor minutes and streak information.

Technical Architecture

The project uses:

Frontend: React + Vite
Backend: FastAPI + Python
Database: SQLite + SQLAlchemy
AI layer: Open-weight Gemma integration with a deterministic fallback
HTTP: httpx
Deployment: Render

The frontend is deployed as a Render Static Site and the FastAPI backend runs as a Render Web Service.

GitHub:
https://github.com/PRAVIN-KUMAR-295/touchgrass-ai

Live Demo:
https://touchgrass-ai-2.onrender.com

How Gemma Is Used

The project was designed around an AI provider abstraction so that an open-weight model can generate outdoor mission content without tightly coupling the application to one provider.

The intended hosted model is:

google/gemma-3-4b-it

The application also includes a deterministic fallback so the core mission experience remains usable when hosted AI credentials are unavailable.

Important disclosure

For the deployed demo, I did not configure a hosted Gemma API key, so I have not claimed that the live deployment is currently performing real Gemma inference.

The deployed application is using the tested deterministic fallback path.

This keeps the demo honest while preserving the open-weight Gemma integration in the architecture.

Why Open Innovation Matters

The open-weight approach makes the AI layer more replaceable and easier to experiment with.

Instead of building the entire application around a closed provider, the AI service is separated from the rest of the product. This makes it possible to change the model or serving infrastructure without redesigning the outdoor mission experience.

For this project, that flexibility is more important than making the AI itself the main attraction.

Taking It Outside

I actually used the deployed application for an outdoor mission.

I generated a mission, started it, put the phone away, went outside, completed the activity, and then returned to mark the mission complete.

The completed mission appeared in History and the Statistics page updated with completed missions, outdoor minutes, and the streak.

This was the part of the project I liked most: the successful outcome was not spending more time inside the app.

Screenshots

Home

Mission Planning

Generated Mission

Mission in Progress

History

Statistics

What I Learned

One of the biggest lessons was that building an AI application does not have to mean building an experience that keeps users interacting with AI.

The best part of TouchGrass AI happens after the AI finishes its job.

I also learned a lot about separating the AI service from the application logic, building a reliable fallback path, testing the complete mission lifecycle, and deploying a React + FastAPI application to production.

AI Disclosure

AI tools were used during development to help with implementation, debugging, documentation, and development workflow.

The project itself was designed, tested, deployed, and verified as a working application.

Final Thoughts

TouchGrass AI started with a simple question:

Can AI help us use our phones less?

Instead of optimizing for another screen session, this project tries to make the screen the shortest part of the experience.

Choose a mission.

Put the phone away.

Go touch grass. 🌱

Built for the Ha

TouchGrass AI: An Open-Source AI Outdoor Mission Planner

PRAVIN KUMAR — Wed, 07 Oct 2026 20:32:57 +0000

TouchGrass AI: An Open-Source AI Outdoor Mission Planner

What if AI helped you spend less time looking at a screen?

That was the idea behind TouchGrass AI, an outdoor mission planner built for the Hacktoberfest 2026 Open-Source AI Challenge: Week 1.

What I Built

TouchGrass AI creates short, practical outdoor missions based on:

Available time: 15, 30, or 60 minutes
Activity: Walking, Nature, Photography, Exercise, or Social
Difficulty: Easy, Medium, or Hard
Mode: Solo or With Friends

Instead of keeping the user inside the app, the goal is to use the screen briefly, get a mission, and then put the phone away.

For example, a 30-minute nature mission can ask you to walk without looking at a screen, observe different plants, notice a natural sound, and spend a few quiet minutes outside.

The Problem

A lot of digital products are designed to keep us on the screen.

For this challenge, I wanted to build the opposite: an AI experience where the screen is only the starting point.

The useful part of the experience happens outside.

The "Touch Grass" Idea

The core interaction is intentionally simple:

Choose → Generate → Go outside → Complete → Come back

The app gives the user an actionable outdoor objective and encourages them to put their phone away once the mission starts.

This makes the AI a short planning tool rather than another reason to keep scrolling.

How It Works

The user selects their available time.
They choose an outdoor activity.
They choose difficulty and solo/friends mode.
The backend creates a structured mission.
The user starts the mission.
The app provides an actionable checklist.
The user goes outside and completes it.
The completed mission is saved to history and reflected in statistics.

TouchGrass AI also keeps a history of completed missions and shows outdoor minutes and streak information.

Technical Architecture

The project uses:

Frontend: React + Vite
Backend: FastAPI + Python
Database: SQLite + SQLAlchemy
AI layer: Open-weight Gemma integration with a deterministic fallback
HTTP: httpx
Deployment: Render

The frontend is deployed as a Render Static Site and the FastAPI backend runs as a Render Web Service.

GitHub:
https://github.com/PRAVIN-KUMAR-295/touchgrass-ai

Live Demo:
https://touchgrass-ai-2.onrender.com

How Gemma Is Used

The project was designed around an AI provider abstraction so that an open-weight model can generate outdoor mission content without tightly coupling the application to one provider.

The intended hosted model is:

google/gemma-3-4b-it

The application also includes a deterministic fallback so the core mission experience remains usable when hosted AI credentials are unavailable.

Important disclosure

For the deployed demo, I did not configure a hosted Gemma API key, so I have not claimed that the live deployment is currently performing real Gemma inference.

The deployed application is using the tested deterministic fallback path.

This keeps the demo honest while preserving the open-weight Gemma integration in the architecture.

Why Open Innovation Matters

The open-weight approach makes the AI layer more replaceable and easier to experiment with.

For this project, that flexibility is more important than making the AI itself the main attraction.

Taking It Outside

I actually used the deployed application for an outdoor mission.

I generated a mission, started it, put the phone away, went outside, completed the activity, and then returned to mark the mission complete.

The completed mission appeared in History and the Statistics page updated with completed missions, outdoor minutes, and the streak.

This was the part of the project I liked most: the successful outcome was not spending more time inside the app.

Screenshots

Home

Mission Planning

Generated Mission

Mission in Progress

History

Statistics

What I Learned

One of the biggest lessons was that building an AI application does not have to mean building an experience that keeps users interacting with AI.

The best part of TouchGrass AI happens after the AI finishes its job.

AI Disclosure

AI tools were used during development to help with implementation, debugging, documentation, and development workflow.

The project itself was designed, tested, deployed, and verified as a working application.

Final Thoughts

TouchGrass AI started with a simple question:

Can AI help us use our phones less?

Instead of optimizing for another screen session, this project tries to make the screen the shortest part of the experience.

Choose a mission.

Put the phone away.

Go touch grass. 🌱

Built for the Hacktoberfest 2026 Open-Source AI Challenge: Week 1.

BuddyLens AI: An Open-Source AI Study Companion Built for a Friend

PRAVIN KUMAR — Sat, 03 Oct 2026 17:38:07 +0000

What I Built

I built BuddyLens AI, an open-source AI study companion that helps students turn their lecture notes and PDFs into something they can actually study from.

Instead of reading through a long PDF and manually creating questions or a revision schedule, a student can upload their notes and use BuddyLens AI to:

Ask questions grounded in their notes
Get simple explanations with relevant section citations
Generate multiple-choice quizzes
Create a prioritized revision plan
Track study activity and insights

The goal was simple: make studying from existing notes more interactive and less overwhelming.

Built for a Friend 🤝

I built BuddyLens AI around a real problem faced by a college friend: studying from long lecture PDFs made it difficult to quickly identify the important concepts, practice questions, and organize what to revise first.

I wanted to build something that could work directly with the notes they already had instead of requiring them to manually convert every lecture into flashcards, questions, and revision plans.

How It Works

The basic flow is:

Upload Notes → Extract Text → Split into Relevant Chunks → Retrieve Relevant Sections → Generate with Gemma → Show the Result

When a student asks a question, BuddyLens first retrieves relevant parts of the uploaded study material. Those sections are then provided as context to the AI model.

This makes the responses grounded in the student's own material rather than relying only on general model knowledge.

The same approach is used for quiz generation and revision planning.

Technical Architecture

BuddyLens AI is a full-stack application with an open-weight AI model at its core.

Frontend

React 19
Vite

Backend

FastAPI
SQLite
pypdf for PDF text extraction

Retrieval

BM25 / TF-IDF based retrieval
Note chunking and relevant-section retrieval

AI

Gemma 3 4B
Model: google/gemma-3-4b-it
Served through an OpenAI-compatible hosted endpoint

Deployment

Frontend: Render
Backend: Render

The application also uses an AI provider abstraction so the AI layer can be changed between different serving approaches. The project includes support for local Ollama-based inference as well as a hosted model configuration.

Why Gemma and Open Innovation Matter

For this project, I wanted the AI layer to be based on an open-weight model rather than tightly coupling the application to a single proprietary model.

BuddyLens AI uses Gemma 3 4B as its AI engine.

Using an open-weight model makes the architecture more flexible. The model can be served through different infrastructure, and the application can keep the retrieval, study logic, and user experience separate from the model provider.

For a student-focused tool, this also makes experimentation easier: the same study workflow can evolve as better open models and serving options become available.

What the App Can Do

1. Grounded AI Q&A

A student can ask questions about their uploaded notes and receive an explanation based on the relevant sections.

The response can include citations back to the study material, making it easier to verify where the answer came from.

2. Active Recall Quiz

BuddyLens can generate multiple-choice questions from the uploaded notes.

The student can answer the questions directly inside Quiz Mode and use the results to identify knowledge gaps.

3. Revision Plan

Instead of simply summarizing the notes, BuddyLens can create a prioritized revision plan based on the uploaded material.

This turns a large set of notes into a smaller set of actionable study steps.

4. Study Insights

The application also provides activity and study insights so the student can see how they are using the study workspace.

Demo

Live application:

https://buddylens-ai-3.onrender.com

Backend:

https://buddylens-ai-2.onrender.com

The live application is running with:

Hosted Gemma (google/gemma-3-4b-it)

Screenshots

AI Q&A with Note Citations

Active Recall Quiz

Revision Plan

Source Code

The complete project is open source on GitHub:

https://github.com/PRAVIN-KUMAR-295/buddylens-ai

What I Learned

Building BuddyLens AI taught me that making an AI application useful is not only about connecting a model to a chat interface.

The retrieval layer, grounding, citations, UI flow, quiz experience, and revision workflow are all important parts of the product.

I also learned how much difference it makes to keep the AI provider separate from the application logic. It makes it easier to experiment with different open models and serving approaches.

AI Disclosure

I used AI coding assistance during development. I reviewed, tested, debugged, and integrated the generated code into the project, and verified the application's backend, frontend build, AI integration, and deployment.

Final Thoughts

BuddyLens AI started with a simple idea: if a student already has their notes, the AI should help them actually learn from those notes.

Instead of replacing the student's study material, BuddyLens works as a study companion around it.

The project is open source, uses Gemma at its core, and is designed so that the AI serving layer can evolve as open models and infrastructure evolve.

Thanks for checking out BuddyLens AI!