DEV Community: Pratyush Mishra

🧾 Munshi — Turning Everyday Grocery Orders into Bills with Local AI

Pratyush Mishra — Sun, 18 Oct 2026 08:25:21 +0000

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

What I Built

Munshi — Local AI Grocery Billing is a grocery billing assistant that converts natural-language orders into itemized bills using locally running AI.

Small grocery and snack shops often handle orders informally, then manually search for products, enter quantities, and calculate totals. Munshi aims to simplify this workflow.

With Munshi, a shopkeeper can enter an order in everyday language. The application extracts product details, matches them against a CSV-based price catalog, and generates a bill containing product names, quantities, prices, and the final total.

The goal is to help small businesses simplify repetitive billing without making a hosted AI API a requirement.

✨ Key Features

🗣️ Natural-language order processing: Describe an order in everyday language.
🤖 Local AI inference: Uses Ollama with Qwen 3.5 4B for order extraction.
🛒 Catalog-based product matching: Matches extracted products against a CSV price list.
🧮 Automatic bill calculation: Calculates quantities, rates, line totals, and the final amount.
⚠️ Unmatched-product handling: Identifies products that need review.
🌐 Interactive web interface: A Streamlit UI makes the workflow accessible.
🧪 Automated testing: Includes tests for billing, catalog matching, extraction, and order processing.

The intended users are small grocery shops, snack shops, and independent shopkeepers who want a simpler billing workflow.

👀 Product Walkthrough

Here is the workflow, from opening the application to reviewing a generated bill.

1. Start with a clean order screen

The clean interface gives the shopkeeper a starting point to enter an order and begin the billing workflow.

2. Enter an order for snacks

The shopkeeper describes the requested items in ordinary language. Munshi uses its local AI model to extract the order details and attempts to match the products against the available catalog.

The key interaction is that the user describes the order naturally instead of manually building every line of the bill.

3. Generate and review the bill

The application displays the matched products, quantities, prices, and calculated total. Products that cannot be matched confidently should be reviewed before the bill is accepted.

This is the core idea behind Munshi: turn an ordinary sentence into a structured bill through a practical combination of AI and conventional application logic.

Demo

Munshi currently runs locally using Streamlit and Ollama.

To launch the application, run:

python -m streamlit run app.py

Then open http://localhost:8501 in your browser.

The three screenshots in this post demonstrate the interface, order entry, and generated bill. Munshi is currently a local application, so I am sharing the source code rather than claiming a publicly deployed demo.

Code

GitHub Repository: munshi-smart-grocery-billing

The repository contains the Streamlit application, order-processing modules, product price catalog, dependency list, and automated tests.

Contributions and suggestions for improving product matching, multilingual order entry, and local AI reliability are welcome.

How I Built It

Munshi combines an open-weight language model with conventional Python application logic.

Technology Stack

Python — application and order-processing logic
Streamlit — interactive web interface
Ollama — local model runtime
Qwen 3.5 4B — open-weight model for extracting order information
Pandas and CSV — product catalog management
Pytest — automated testing

How the System Works

The shopkeeper enters a grocery order in natural language.
Qwen 3.5 4B, running locally through Ollama, extracts structured order details.
The application matches extracted product names against the CSV catalog.
Python billing logic calculates the line totals and final amount.
Streamlit displays the generated bill for review.

A key design decision was to use AI for understanding the order and ordinary application code for catalog matching and arithmetic. This keeps billing calculations testable rather than relying on the language model to calculate prices correctly.

During development, the project's test suite passed 14 tests locally.

Why Does Open Innovation Matter?

A small-shop billing tool should not necessarily require a paid AI API, a constant internet connection for model inference, or sending order text to a third-party model provider.

Open-weight models and local inference make another approach possible.

By using Ollama with Qwen 3.5 4B, Munshi can perform its order-extraction workflow on the shopkeeper's own computer without requiring a hosted LLM API. This makes experimentation more accessible and gives developers greater control over the model and deployment environment.

Open innovation also allows other developers to inspect, modify, and extend the project. They could adapt the catalog to local products, improve fuzzy matching, add regional-language support, or introduce printable receipts and billing history.

Local inference does not automatically guarantee privacy or perfect accuracy, and product matches still need appropriate validation. However, it provides a useful foundation for building practical AI tools without making hosted inference a requirement.

For me, open innovation is about more than accessing a model's weights. It is about using accessible technology to build tools that solve everyday problems.

Prize Categories

Submitting Munshi to the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

🚀 What's Next?

There is plenty of room to grow Munshi:

🌐 Support more regional and Indian-language grocery orders.
🔍 Improve product matching for misspellings and locally used product names.
✏️ Add editable quantities and a bill-confirmation step.
🧾 Introduce printable receipts and persistent billing history.
📊 Evaluate extraction accuracy against a collection of realistic grocery orders.
🛠️ Make setup easier for shopkeepers who are not technical users.

The long-term vision is to build a simple, affordable, local-first billing assistant that helps small shops spend less time on repetitive manual entry.

🙌 Final Thoughts

Building Munshi helped me explore how an open-weight model can fit into a practical application rather than remain just a chat interface.

The interesting part was not simply connecting an LLM. It was combining natural-language understanding with a product catalog, predictable calculations, a usable interface, and automated tests.

That is the kind of practical open-source AI I want to keep building: useful, inspectable, and accessible to more people.

If you have suggestions for improving local AI billing, I'd love to hear them!

Explore the code: munshi-smart-grocery-billing

🤖🌿 I Taught AI to Touch Grass. It Gave Me a Mission, Not an Answer.

Pratyush Mishra — Sun, 11 Oct 2026 12:13:47 +0000

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

What I Built

🤖🌿 What if AI stopped giving you more things to read and started giving you reasons to explore the real world?

That's the idea behind OutsideQuest — an open-source AI project powered by Qwen 3.5 4B running locally through Ollama. It turns ordinary outdoor moments into curiosity-driven observation missions.

We often use AI to write, code, summarize, and automate tasks. With OutsideQuest, I wanted to explore a different possibility: what if AI encouraged us to spend less time staring at screens and more time noticing the world around us?

OutsideQuest generates outdoor missions that encourage users to observe, question, and investigate their surroundings.

Some of its mission categories include:

🔊 Sound Detective: Pay attention to sounds around you and investigate their possible sources.
🌗 Light & Shadow: Observe how sunlight, shadows, and lighting change your surroundings.
🌱 Urban Nature Mystery: Explore small details of nature around you.
🏙️ Human Impact: Notice how human activities affect the environment.
🔎 Micro-Discovery: Investigate an ordinary detail more carefully.

The app also includes a local discovery journal that saves observations in discoveries.json. Its follow-up investigation feature helps users turn observations into hypotheses and consider what they could investigate next.

It's designed for curious people, students, and anyone who wants a simple reason to explore their surroundings.

The goal isn't to make AI do all the thinking. It's to use AI to encourage people to observe, think, and discover things for themselves.

Demo

OutsideQuest currently runs locally on my machine using Ollama and Qwen 3.5 4B. I haven't deployed a public hosted version yet.

OutsideQuest Dashboard

Discovery Journal

To run the application, follow the setup instructions in the GitHub repository.

Code

🌿 GitHub Repository: https://github.com/pratyushmishra9920-ship-it/outsidequest-ai

The repository contains the project source code, README, and instructions for running the application locally.

Feel free to explore the code and share suggestions or ideas for improving the project.

How I Built It

I wanted to experiment with an open-weight model that could run locally rather than making the entire experience dependent on a hosted AI API.

Here's the technology stack:

Python: Application logic and data handling.
Streamlit: Interactive web interface.
Ollama: Local model runtime.
Qwen 3.5 4B: The model used to generate outdoor missions.
JSON: Local storage for the discovery journal.

How the application works

The user selects an outdoor mission category.
The application sends a prompt to the locally running model through Ollama.
The model generates an observation mission.
The user explores their surroundings and records an observation.
The follow-up investigation flow helps the user develop a hypothesis and consider a possible next experiment.
The observation is saved in the local discovery journal.

One of my main design decisions was to build around an actual real-world activity instead of creating another chatbot interface.

I also wanted the missions to be accessible. They shouldn't require expensive equipment or assume that everyone has access to a particular park, garden, or outdoor location.

Why Does Open Innovation Matter?

Open innovation gives developers the freedom to experiment, learn from existing tools, and explore ideas beyond conventional use cases.

For OutsideQuest, using an open-weight model locally allowed me to experiment with AI-powered mission generation without making a hosted model API the centre of the application.

Local inference also means prompts can be processed by the model on the user's machine rather than being sent to a remote model provider. The model must be installed locally, and the application currently runs on the user's computer.

But the idea goes beyond the technology itself.

AI is often used to help us work faster, automate tasks, and spend more time interacting with digital tools. I wanted to explore another possibility: Can AI help us reconnect with the physical world instead?

OutsideQuest uses AI to suggest what to investigate, but the actual experience happens outside the screen. The user still has to observe their surroundings, think critically, and decide what to investigate.

Open tools made it possible for me to experiment with this idea using local inference and build an experience that doesn't look like a traditional AI chatbot.

Sometimes, the best AI-generated response is a reason to put your phone away and go outside.

My Agent Session

The project uses Ollama with Qwen 3.5 4B for local inference.

I don't have a separate, verified DevRelay agent-session link to share, so I've included the GitHub repository as the main reference for the project.

Prize Categories

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

What's Next?

OutsideQuest is a starting point, and I have several ideas for improving it:

Making missions more varied and responsive to users' observations.
Improving the follow-up investigation flow.
Adding better ways to revisit and reflect on previous discoveries.
Making the application easier to set up on different machines.

For now, the core experience is deliberately simple:

Get a mission. Step outside. Pay attention. Discover something. 🌿

I'd love to hear your thoughts.

If you could build an AI tool that encouraged people to spend more time in the real world, what would it do?

devchallenge #hf26challenge

Aakhri Tareekh: An Offline AI That Finds Deadlines in College Notices

Pratyush Mishra — Mon, 05 Oct 2026 06:02:26 +0000

Aakhri Tareekh — आख़िरी तारीख

An offline-first college notice reader for the friend who keeps missing deadlines.

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

What I Built

College notices are often long, messy PDFs or scanned documents. Important dates can be buried inside several pages, and missing one deadline can mean missing a registration, payment, examination, or application.

I built Aakhri Tareekh (आख़िरी तारीख) for a friend who repeatedly discovers important college deadlines too late.

The app turns a college notice into a clear set of actions:

Finds deadlines from notice pages
Identifies the required action
Identifies who the deadline applies to
Extracts fees and required documents
Shows supporting evidence for each deadline
Marks ambiguous dates as unclear instead of guessing
Lets confirmed dates be exported as .ics calendar events

The core idea is simple:

Turn a messy college notice into one trustworthy next action.

Demo

The project currently runs locally with Ollama and does not require a cloud AI API.

Demo flow:

Upload a college notice PDF or image.
Select the page containing the relevant dates.
Qwen3.5-4B reads the page locally.
The application extracts deadlines, actions, audience, fees, and evidence.
Confirmed dates can be exported as an .ics calendar event.

GitHub repository: https://github.com/pratyushmishra9920-ship-it/aakhri-tareekh

Code

The project is built with:

Python
FastAPI
HTML/CSS/JavaScript
Ollama
Qwen3.5-4B
PyMuPDF for PDF page rendering
ICS calendar export

The repository contains the complete application, setup instructions, requirements, and the dashboard screenshot.

How I Built It

The AI core uses the open-weight Qwen3.5-4B model locally through Ollama.

A selected notice page is rendered as an image and passed to the local model with a strict extraction prompt. The model returns structured JSON containing the title, deadlines, actions, audience, fees, documents, summary, and evidence.

I deliberately designed the extraction process to be conservative.

The system is instructed to:

Extract a deadline only when an actual date is visibly written on the current page.
Never infer a date from another page, annexure, website, or cross-reference.
Never silently change a visible year.
Preserve date ranges instead of converting them into a single date.
Return null and unclear when a date is ambiguous or uncertain.
Require evidence for every extracted deadline.
Avoid turning ordinary dates into deadlines.

This matters because a wrong deadline can be worse than no deadline at all.

For example, if a notice contains a date range such as 15 July 2026 to 19 July 2026, the application does not arbitrarily choose one of those dates as the deadline. It preserves the range and marks it as unclear when a single calendar date cannot safely be determined.

Why Does Open Innovation Matter?

Using an open-weight model locally changes what this application can do.

Privacy: College notices can contain academic, registration, payment, or student information. The document can remain on the user's machine.

Offline-first: After downloading the model, notice analysis can run locally without sending documents to a cloud AI service.

No per-notice API bill: Local inference means there is no cloud API request for every notice.

Model freedom: Because the application communicates with Ollama, the underlying model can be replaced or upgraded later.

Custom behavior: The extraction process can be specifically designed around college notices and a strict no-guessing policy rather than relying on a generic document summarizer.

The open model is therefore not just a cheaper replacement for a closed API. It gives me control over where the data goes and how the model is used.

My Agent Session

I used AI coding assistance while developing the project.

I did not complete a DevRelay session that I can provide as a verified agent-session artifact for this submission, so I am not claiming a DevRelay-specific category.

Prize Categories

This submission is for the Overall Winner of the Hacktoberfest Weekend Challenge: Build for a Friend.

I am not claiming a partner-specific prize category that requires technology I did not actually use in this project.

The Friend Behind It

The project started from a very practical problem.

A friend kept missing important college deadlines because the information was buried inside notices that were difficult to scan quickly.

I could have built a generic AI document summarizer, but that would not solve the actual problem.

Instead, I focused the application on one specific outcome:

What do I need to do, and when do I need to do it?

That focus influenced the entire design — especially the evidence shown alongside each extracted deadline and the decision to say unclear instead of guessing.

What I Learned

The biggest lesson from building Aakhri Tareekh was that an AI application does not always need to be more confident.

For a deadline extractor, knowing when not to guess is a feature.

Working with a local open-weight vision model also made me think about the complete AI system rather than treating an API call as the whole application.

The project started as a simple idea for one friend, but it became a useful example of how local open AI can be combined with a focused workflow to solve a very specific real-world problem.

Built for the Hacktoberfest Weekend Challenge: Build for a Friend.

devchallenge #weekendchallenge #hf26challenge

I Built an AI That Legally Cannot Help You — Meet TeaGPT

Pratyush Mishra — Sun, 12 Apr 2026 14:06:30 +0000

This is a submission for the DEV April Fools Challenge

What I Built

TeaGPT — a ChatGPT parody that is, as per RFC 2324, legally an HTTP 418 Teapot.

Ask it anything. It refuses. It recommends tea. Every time. This is a feature, not a bug.

Demo

🍵 https://teapot-talk-ai.lovable.app

Code

https://github.com/pratyushmishra9920-ship-it/teapot-talk-ai

How I Built It

React + TypeScript + Vite + Tailwind CSS + Pollinations AI (free, no API key needed). Built with Lovable, deployed on Vercel.

Prize Category

Best Ode to Larry Masinter — every 418 badge, the $4.18 pricing, the TeaPot-4o model — all a tribute to RFC 2324.

Community Favorite — go ask it to fix your code. It won't. Status: 418.