DEV Community: Krishna Kumar

LazyDesk AI: Let Open AI Handle the Boring Document Work

Krishna Kumar — Sat, 24 Oct 2026 15:14:32 +0000

What I Built

As developers, we spend a lot of time reading documentation, reviewing project briefs, and turning lengthy documents into actionable tasks. The work is necessary, but much of it is repetitive.

I built LazyDesk AI, a local-first document assistant that helps automate the boring parts of document processing.

With LazyDesk AI, you can:

Summarize documents: Upload a PDF or TXT file and generate a concise summary.

Extract action items: Identify tasks and deadlines explicitly mentioned in the document.

Export results: Download generated summaries and action items as Markdown.

Run AI locally: Use an open-weight model through Ollama instead of relying on a hosted AI API.

The idea behind LazyDesk AI is simple: spend less time manually processing documents and more time acting on the information they contain.

It is designed for students, developers, and anyone who regularly works with technical documentation, project notes, or lengthy text files.

Code

💻 GitHub Repository: https://github.com/Krishnakumar7255/LazyDesk-AI

The project is open source and available for developers to explore, run locally, and improve.

How I Built It

LazyDesk AI uses a straightforward Python-based architecture.

Tech stack:

Python for application logic

Streamlit for the user interface

Ollama for local model inference

Gemma 2 2B as the open-weight language model

pypdf for extracting text from PDFs

The workflow is simple:

A user uploads a PDF or TXT document.

The application extracts the document's text.

The text is passed to Gemma through the local Ollama runtime.

The model generates a summary or extracts actionable information.

The user reviews the result and downloads it as Markdown.

The default model is gemma2:2b.

Because inference runs locally, the application does not need a paid hosted AI API key for its default workflow. After the model has been downloaded, the core workflow can also run without an internet connection, provided the local dependencies and model are available.

Why Does Open Innovation Matter?

For LazyDesk AI, open innovation is about control, privacy, flexibility, and accessibility.

Keep document processing local

Documents can contain personal notes, academic work, or internal project information. Running inference locally means the extracted text does not need to be sent to an external AI provider.

Reduce dependence on paid APIs

Hosted AI services may charge for each request or impose usage limits. With LazyDesk AI, local inference avoids per-request hosted API charges, although the computer still consumes electricity and requires sufficient hardware.

Experiment with different models

Using Ollama makes it possible to experiment with compatible locally installed models and compare their outputs. Developers can adapt the workflow instead of depending entirely on one closed provider.

Make offline AI practical

Once the model and dependencies are installed, the application can process supported documents without an active internet connection. This is useful when connectivity is unreliable or documents should remain on the user's machine.

A closed API can make model access convenient, but local open-weight inference gives this project something important: the ability to run its core AI workflow under the user's control.

Local execution is not a guarantee of perfect privacy or accuracy, and model licenses and hardware requirements still matter. Generated summaries and extracted tasks should always be checked against the original document.

My Agent Session

Optional: [Add your DevRelay agent session link here]

I will include an agent session if available so others can explore the development process behind the project.

The Lazy Payoff

The best automation is the kind that removes a repetitive step from your everyday workflow.

Imagine receiving a long project brief. Instead of manually rewriting its contents into notes, you can start with an AI-generated summary and a list of potential action items, then verify them against the original document.

That gives you a more manageable starting point without pretending that AI removes the need for judgment.

I have not included an unverified time-saving percentage or accuracy score. A useful next step is to compare manual processing time against LazyDesk AI on the same document and measure how much editing the generated output requires.

My goal is to make document processing less tedious, not to generate impressive-looking numbers without evidence.

Prize Categories

Primary challenge: Hacktoberfest Open-Source AI Challenge — Week 3: Slow and Steady.

Potential partner category: Best Use of Gemma, because Gemma is the open-weight model used in LazyDesk AI.

The Gemma category is the most directly relevant partner category for this implementation. Any additional category should only be selected if the project actually uses that partner's technology.

Sometimes productivity is not about doing more. Sometimes it is about eliminating the boring work that gets in the way.

Build less busywork. Keep more time for building. 🦥

devchallenge #hf26challenge

MenuMitra AI: Building a Local-First AI Menu Translator for Small Restaurants

Krishna Kumar — Sun, 18 Oct 2026 15:33:33 +0000

🍽️ Introducing MenuMitra AI

Small restaurants and cafés often need menus in multiple languages, but translating and formatting menus can take time and money. I wanted to explore how open-source AI could make this process more accessible.

That's why I'm building MenuMitra AI — a local-first AI menu translation tool designed for restaurants, cafés, and small food businesses.

💡 The Problem

A restaurant may want to serve customers who speak different languages, but creating and maintaining multilingual menus can be difficult. Small businesses may also have privacy concerns when uploading business data to external AI services.

🚀 My Solution

MenuMitra AI aims to help restaurants translate menu items and create menus that are easier to share and print.

The project is designed around these capabilities:

🌐 AI-assisted menu translation

🍛 Keeping original dish names where appropriate

💰 Preserving menu prices from the source data

📄 Importing and exporting menu data using CSV

🖨️ Creating a printable menu through the browser

🔒 Using a locally running model to reduce the need to send menu content to an external AI API

🛠️ Tech Stack

Python — application logic

FastAPI — backend API

Ollama — running a language model locally

Qwen2.5 — the default model configured in the prototype

The exact model and its license should be checked before redistribution or commercial deployment.

🌱 Why Open-Source AI?

Open-source tools give developers and small businesses more control over how software is used and customized.

With a local model, a business can potentially process its menu content on its own machine after downloading the required model. This can reduce reliance on paid, per-request AI APIs. However, local inference still requires suitable hardware and consumes computing resources.

I also want this project to be open to contributions, including better regional-language support, improved translations, and feedback from restaurant owners.

🔗 GitHub Repository

Explore the project and contribute:

👉 https://github.com/Krishnakumar7255/MenuMitraAI

🧪 Current Status

MenuMitra AI is a prototype, and its functionality and translation quality need to be verified through local testing and real-world feedback.

AI-generated translations may contain errors. Restaurant owners should review the final menu, especially prices, ingredients, and allergen information, before using it with customers.

🙌 What's Next?

I'd like to improve the project with feedback from developers and small-business owners.

Some ideas I'm exploring include:

Support for more Indian languages

Better handling of regional dish names

More menu templates

A smoother workflow for restaurant owners

I'd love your feedback!

If you run a restaurant or café, what would make a tool like this genuinely useful for your business? And if you're a developer, what feature would you contribute first?

OpenSourceAI #BuildInPublic

BirdSnap Offline: Identify Bird Calls with Local AI

Krishna Kumar — Wed, 07 Oct 2026 17:14:41 +0000

BirdSnap Offline is a Python-based bird-call identification app that uses the BirdNET AI model locally.

The idea is simple:

Go outside → Record a bird call → Identify it → Learn → Put the screen down → Explore nature 🌿

The app supports microphone recording, audio uploads, bird identification, confidence scores, alternative predictions, and local observation history.

Code

💻 GitHub Repository:
https://github.com/Krishnakumar7255/BirdSnap-Offline

How I Built It

BirdSnap is built entirely with Python.

Tech Stack

Python
Streamlit
BirdNET
ONNX local inference
JSON

Architecture

🎙️ Microphone / Audio Upload
            ↓
      Streamlit Interface
            ↓
    birdnet_service.py
            ↓
       BirdNET Model
            ↓
   Bird Species + Confidence
            ↓
     Local Observation History

No React, Node.js, FastAPI, or separate backend is required.

Why Does Open Innovation Matter?

BirdSnap uses local AI instead of depending on a closed cloud AI API.

This provides:

🔒 Better privacy for recordings
🧠 Local AI inference
🌐 Less dependency on cloud AI services
🔄 Ability to experiment with different open models
🛠️ More control for developers

The BirdNET ecosystem also supports local/offline inference once the required model assets are available.

🌿 How It Supports "Touch Grass"

BirdSnap is designed so that AI is only a small part of the experience.

The goal is not to spend more time looking at a screen.

Instead:

Record → Identify → Learn → Put the phone down → Explore 🌳

A user can record a bird call, quickly identify it, learn something about it, and then continue observing nature.

🧪 Outdoor Test

For the real-world test, I plan to:

Go outside with the device.
Find a bird or hear a bird call.
Record the sound.
Run BirdSnap.
Check the prediction and confidence.
Put the device down.
Continue exploring and observing the bird.

🏆 Prize Categories

Primary Challenge:
Hacktoberfest Open-Source AI Challenge — Week 1

Theme:
🌿 Touch Grass

Add partner prize categories here only if BirdSnap genuinely qualifies for them.

🤖 My Agent Session

If you used an AI coding agent while building the project, add the session/share link here.

Otherwise:

Not applicable.

🔮 Future Improvements

GPS-based bird filtering
Bird observation map
Species information cards
CSV export
Better noise reduction
Mobile/PWA support
Daily outdoor challenges
More offline capabilities

📜 License

The application code is intended to use the MIT License.

BirdNET model files have separate licensing terms, so the applicable model license should be checked before redistribution or commercial use.

🌱 Final Thought

AI should not always keep us on screens. Sometimes, the best AI experience is the one that helps us put the screen down.

BirdSnap: Hear it. Identify it. Learn it. Then go find it. 🐦🌿

I Built a Customer Support AI System to Help a Friend Find Answers Faster

Krishna Kumar — Mon, 05 Oct 2026 05:00:33 +0000

I built a Customer Support AI System to help a friend who was practicing customer-support workflows and needed a faster way to find accurate answers from support documentation.

A common problem in customer support is that the information already exists, but finding the right piece of information can take time.

Support teams may have FAQs, refund policies, account policies, payment documentation, and other reference documents spread across multiple files.

Instead of manually searching through those documents, I built a system that allows support knowledge to be uploaded and searched using semantic similarity.

The system can:

Upload FAQ, support, policy, PDF, TXT, and Markdown documents
Extract document text
Clean and split the text into overlapping chunks
Generate embeddings
Store embeddings in ChromaDB
Perform semantic search
Return relevant chunks with source metadata
Track the original document and page for retrieved information

The goal is simple:

Help a support agent find the right information faster.

Demo

The project includes a Streamlit demonstration interface for interacting with the knowledge base.

Example questions

The system can be tested with questions such as:

How long do customers have to request a refund?
What should I do if my account is locked?
How quickly are password reset emails sent?
Which payment methods are supported?
Can a refund be requested after 30 days?

The repository also provides a FastAPI backend and Swagger documentation for interacting with the API.

Demo:
https://github.com/Sinjini1803/Customer-Support-System

Code

The complete source code is available here:

GitHub:
https://github.com/Sinjini1803/Customer-Support-System

The repository contains the application code, sample data, tests, Docker configuration, ingestion pipeline, and demonstration interface.

How I Built It

The system is built around a Retrieval-Augmented Generation-style knowledge pipeline, with the current implementation focusing on the retrieval stage.

The architecture is:

The repository implements PDF/text extraction using PyMuPDF, creates overlapping chunks, generates normalized embeddings using Sentence Transformers, and persists those vectors in ChromaDB.

Document Ingestion

A support document can be uploaded through the API.

For example:

curl -X POST http://localhost:8000/ingest \
-F "file=@data/sample_documents/refund_policy.pdf"

The system extracts the document content and divides it into manageable chunks.

Each chunk retains metadata such as:

Document ID
Document name
Document type
Page number
Chunk number
Source filename
Upload timestamp

This means that a search result can be traced back to its original document and page.

Embeddings

After the document is processed, the text chunks are converted into numerical vector representations using a Sentence Transformer model.

This allows the system to compare the meaning of a user's question with the meaning of stored support information rather than relying only on exact keyword matches.

ChromaDB

The generated embeddings are stored in ChromaDB.

When a user asks a question, the question is also converted into an embedding.

The system then performs semantic similarity search and retrieves the most relevant chunks.

User Question
|
v
Query Embedding
|
v
ChromaDB Search
|
v
Top-K Relevant Chunks
|
v
Document + Page Metadata

The current API returns the chunk text, similarity score, document information, page number, chunk ID, and source filename.

FastAPI Backend

The backend is implemented using FastAPI.

The project provides endpoints for:

Health checking
Document ingestion
Semantic search

It also exposes Swagger documentation through:

http://localhost:8000/docs

when running locally.

Streamlit Demo

A Streamlit interface provides a simple way to interact with the knowledge base without having to manually call API endpoints.

The project can be started with:

streamlit run demo/streamlit_app.py

The repository also includes Docker and Docker Compose support.

Why Does Open Innovation Matter?

Open innovation mattered to this project because I wanted to understand how much of an AI-powered support workflow could be built using open tools rather than relying entirely on a closed AI API.

The project uses open-source components for the core retrieval pipeline:

Sentence Transformers for embeddings
ChromaDB for vector storage
FastAPI for the backend
Streamlit for the demonstration interface

This gives developers more control over the individual parts of the system.

Flexibility

The embedding model can be changed independently from the vector database and API layer.

The retrieval system is therefore not tied to one proprietary provider.

Transparency

Because the retrieval pipeline is built from separate components, it is easier to understand how documents are processed, embedded, stored, and retrieved.

Privacy and Control

Customer-support documentation can contain information that organizations may not want to send to an external service for every search.

Using locally controllable components gives developers more flexibility when designing a privacy-conscious system.

Learning

Building the project also helped me understand that an AI application is not just about generating text.

A useful system needs:

Good document processing
Good chunking
Meaningful embeddings
Efficient retrieval
Source tracking
Testing
A usable interface
A Small but Important Design Choice

One thing I wanted to preserve was source traceability.

When a support agent gets a search result, simply returning a piece of text is not enough.

The system stores metadata that can identify the original document and page.

For example:

Document: refund_policy.pdf
Page: 3
Chunk: 2
Similarity: 0.XX

This makes the retrieved information easier to verify.

For customer support, that matters because an answer should ideally be backed by the actual support documentation.

What I Learned

The biggest lesson from building this project was that retrieval quality is extremely important in AI applications.

Before working on this project, it was easy to think of an AI system mainly as a model that generates an answer.

But building the retrieval pipeline showed me that the quality of the information supplied to an AI system matters just as much.

If documents are poorly extracted, badly chunked, or difficult to retrieve, even a powerful language model would have difficulty producing a reliable answer.

This project therefore helped me understand the foundation behind RAG systems:

Documents → Chunks → Embeddings → Vector Search → Relevant Context

The current implementation intentionally separates retrieval from answer generation. The repository documents how an LLM could be added after semantic search to generate a grounded support answer with citations in a future iteration.

My Agent Session

Optional: I did not include a DevRelay session for this submission.

Prize Categories

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

I am only entering additional partner categories when the required partner technology is actually used in the project.

Final Thoughts

I started this project with a simple problem:

Customer-support information is useful only when people can find it quickly.

That led me to build a searchable knowledge system that turns support documents into a semantic knowledge base.

What began as a way to help someone practice customer-support workflows became a practical exploration of document processing, embeddings, vector databases, semantic search, APIs, and AI application architecture.

The most important lesson for me was that building useful AI is not always about creating the biggest model.

Sometimes it is about building a better path between a person's question and the information they actually need.

That is what I wanted to build for my friend.

devchallenge #weekendchallenge #hf26challenge

I Built a Customer Support AI System to Help a Friend Find Answers Faster

Krishna Kumar — Sun, 04 Oct 2026 20:09:26 +0000

What I Built

I built a Customer Support AI System to help a friend who was practicing customer-support workflows and needed a faster way to find accurate answers from support documentation.

A common problem in customer support is that the information already exists, but finding the right piece of information can take time.

Support teams may have FAQs, refund policies, account policies, payment documentation, and other reference documents spread across multiple files.

Instead of manually searching through those documents, I built a system that allows support knowledge to be uploaded and searched using semantic similarity.

The system can:

The goal is simple:

Help a support agent find the right information faster.

Demo

The project includes a Streamlit demonstration interface for interacting with the knowledge base.

Example questions

The system can be tested with questions such as:

The repository also provides a FastAPI backend and Swagger documentation for interacting with the API.

Demo:
https://github.com/Sinjini1803/Customer-Support-System

Code

The complete source code is available here:

GitHub:
https://github.com/Sinjini1803/Customer-Support-System

The repository contains the application code, sample data, tests, Docker configuration, ingestion pipeline, and demonstration interface.

How I Built It

The system is built around a Retrieval-Augmented Generation-style knowledge pipeline, with the current implementation focusing on the retrieval stage.

The architecture is:

The repository implements PDF/text extraction using PyMuPDF, creates overlapping chunks, generates normalized embeddings using Sentence Transformers, and persists those vectors in ChromaDB.

Document Ingestion

A support document can be uploaded through the API.

For example:

curl -X POST http://localhost:8000/ingest \
-F "file=@data/sample_documents/refund_policy.pdf"

The system extracts the document content and divides it into manageable chunks.

Each chunk retains metadata such as:

Document ID
Document name
Document type
Page number
Chunk number
Source filename
Upload timestamp

This means that a search result can be traced back to its original document and page.

Embeddings

After the document is processed, the text chunks are converted into numerical vector representations using a Sentence Transformer model.

This allows the system to compare the meaning of a user's question with the meaning of stored support information rather than relying only on exact keyword matches.

ChromaDB

The generated embeddings are stored in ChromaDB.

When a user asks a question, the question is also converted into an embedding.

The system then performs semantic similarity search and retrieves the most relevant chunks.

User Question
|
v
Query Embedding
|
v
ChromaDB Search
|
v
Top-K Relevant Chunks
|
v
Document + Page Metadata

The current API returns the chunk text, similarity score, document information, page number, chunk ID, and source filename.

FastAPI Backend

The backend is implemented using FastAPI.

The project provides endpoints for:

Health checking
Document ingestion
Semantic search

It also exposes Swagger documentation through:

http://localhost:8000/docs

when running locally.

Streamlit Demo

A Streamlit interface provides a simple way to interact with the knowledge base without having to manually call API endpoints.

The project can be started with:

streamlit run demo/streamlit_app.py

The repository also includes Docker and Docker Compose support.

Why Does Open Innovation Matter?

Open innovation mattered to this project because I wanted to understand how much of an AI-powered support workflow could be built using open tools rather than relying entirely on a closed AI API.

The project uses open-source components for the core retrieval pipeline:

Sentence Transformers for embeddings
ChromaDB for vector storage
FastAPI for the backend
Streamlit for the demonstration interface

This gives developers more control over the individual parts of the system.

Flexibility

The embedding model can be changed independently from the vector database and API layer.

The retrieval system is therefore not tied to one proprietary provider.

Transparency

Because the retrieval pipeline is built from separate components, it is easier to understand how documents are processed, embedded, stored, and retrieved.

Privacy and Control

Customer-support documentation can contain information that organizations may not want to send to an external service for every search.

Using locally controllable components gives developers more flexibility when designing a privacy-conscious system.

Learning

Building the project also helped me understand that an AI application is not just about generating text.

A useful system needs:

Good document processing
Good chunking
Meaningful embeddings
Efficient retrieval
Source tracking
Testing
A usable interface
A Small but Important Design Choice

One thing I wanted to preserve was source traceability.

When a support agent gets a search result, simply returning a piece of text is not enough.

The system stores metadata that can identify the original document and page.

For example:

Document: refund_policy.pdf
Page: 3
Chunk: 2
Similarity: 0.XX

This makes the retrieved information easier to verify.

For customer support, that matters because an answer should ideally be backed by the actual support documentation.

What I Learned

The biggest lesson from building this project was that retrieval quality is extremely important in AI applications.

Before working on this project, it was easy to think of an AI system mainly as a model that generates an answer.

But building the retrieval pipeline showed me that the quality of the information supplied to an AI system matters just as much.

If documents are poorly extracted, badly chunked, or difficult to retrieve, even a powerful language model would have difficulty producing a reliable answer.

This project therefore helped me understand the foundation behind RAG systems:

Documents → Chunks → Embeddings → Vector Search → Relevant Context

My Agent Session

Optional: I did not include a DevRelay session for this submission.

Prize Categories

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

I am only entering additional partner categories when the required partner technology is actually used in the project.

Final Thoughts

I started this project with a simple problem:

Customer-support information is useful only when people can find it quickly.

That led me to build a searchable knowledge system that turns support documents into a semantic knowledge base.

The most important lesson for me was that building useful AI is not always about creating the biggest model.

Sometimes it is about building a better path between a person's question and the information they actually need.

That is what I wanted to build for my friend.

devchallenge #weekendchallenge #hf26challenge

New one on DEV

Krishna Kumar — Sun, 04 Oct 2026 19:58:13 +0000

First time on DEV