DEV Community: Ansh Rajpoot

Lazy Notes: Let Local AI Do the Reading for You

Ansh Rajpoot — Mon, 26 Oct 2026 04:43:22 +0000

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

What I Built

Ever opened a long meeting transcript or a pile of lecture notes and wished someone would just tell you what matters?

That's why I built Lazy Notes — a lightweight AI-powered note summarizer that helps people spend less time reading and more time doing.

Users can paste their notes or upload a text file and generate:

Quick Summary: Understand the main idea without reading every line.
Key Takeaways: Get the important points in bullet form.
Action Items: Identify tasks and deadlines mentioned in the notes.
Two-Line Recap: Get the essential information at a glance.

The idea is simple: let AI handle the repetitive reading so you don't have to.

Demo

Code

💻 GitHub Repository:

ansh-rajpoot / lazy-noted

The project is built with Python and Streamlit, with Ollama powering local AI inference.

How I Built It

I used Python, Streamlit, and Ollama to build Lazy Notes.

Streamlit provides the user interface, while Ollama runs an open-weight language model locally to process the notes and generate structured summaries.

The workflow is straightforward:

The user pastes notes or uploads a supported text file.
The application sends the text to the locally running Ollama model.
The model generates a summary, key takeaways, and action items.
The results are displayed in a clean interface that is easy to read and use.

I kept the architecture simple and focused on building a useful tool rather than adding unnecessary complexity.

Why Does Open Innovation Matter?

For a tool that processes personal notes, meeting discussions, and study material, where the data goes matters.

Using a locally running open-weight model means Lazy Notes can process text without relying on a paid, third-party AI API.

This approach offers several advantages:

More control over data: Notes can remain on the user's machine when Ollama is configured locally and no other external services are used.
Model flexibility: Users can experiment with different compatible models instead of being locked into one hosted AI provider.
Lower ongoing costs: Local inference does not require paying a per-request AI API fee, although hardware and electricity still have costs.
More independence: The core summarization workflow can run without an internet connection once the required model is installed, provided the local setup is working.

Open innovation makes it possible to build a practical AI tool that users can run and control themselves.

The Lazy Payoff

The goal of Lazy Notes is to reduce the effort involved in reviewing long notes.

Instead of manually searching for the main ideas, users can start with a concise summary and review the details that matter to them.

I designed this project around one question:

What if getting the gist of your notes took less effort than reading them all?

Prize Categories

[Add only the partner prize categories that your project genuinely qualifies for, based on the official challenge rules.]

The Cheapest Supplier Wasn't Actually the Cheapest — So I Built QuoteDiff with Local AI

Ansh Rajpoot — Sat, 17 Oct 2026 14:44:47 +0000

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

What I Built

Imagine you're running a small business and need to buy materials from three different suppliers.

One sends a PDF quotation. Another sends an Excel sheet. The third sends a quotation with different product descriptions, delivery charges, and tax details.

At first glance, one supplier looks cheaper. But does that price include GST? Is delivery included? Are the products actually the same grade, size, and quantity?

Comparing quotations manually can be time-consuming, and overlooking one small detail can turn a seemingly good deal into an expensive mistake.

That's the problem I wanted to tackle with QuoteDiff.

QuoteDiff is a local-first, AI-powered supplier quotation comparison tool designed for small businesses, contractors, and procurement teams.

It aims to help users:

Upload supplier quotations in supported document formats.
Extract supplier details, product descriptions, prices, quantities, taxes, and delivery charges.
Compare products while highlighting differences in specifications and units.
Flag missing information, uncertain matches, and incompatible quotations.
Calculate comparable costs using deterministic Python logic rather than asking an AI model to do the arithmetic.
Export a comparison report to support purchasing decisions.

The goal isn't simply to find the lowest number. It's to help users understand whether they're comparing equivalent offers in the first place.

Demo

Code

GitHub repository:

QuoteDiff

Local-first AI app that compares supplier quotations for small businesses.

Inference runs on your machine through Ollama + Gemma. No paid APIs, no cloud database, no authentication. Document parsing, AI extraction, matching, calculations, UI, and exports are separate modules. Calculations are always deterministic Python — the model never invents prices, taxes, or specs.

Designed for an Apple Silicon Mac with 8 GB RAM using a small local model (gemma2:2b by default).

macOS setup

1. Prerequisites

macOS on Apple Silicon
Python 3.11+ (python3 --version)
Ollama for local inference

Install Ollama (pick one):

# Homebrew
brew install ollama

# Or download the macOS app from https://ollama.com/download

2. Start Ollama and download the model

# Start the local server (leave this running)
ollama serve

In a second terminal:

# Small Gemma build suitable for ~8 GB unified memory
ollama pull gemma2:2b

# Confirm it is installed
ollama list

…

View on GitHub

How I Built It

QuoteDiff is designed around open-source tools and local AI inference.

The planned technology stack includes:

Python for the application and comparison engine.
Streamlit for the user interface.
Ollama + Gemma for local AI-powered extraction and interpretation.
Pydantic for validating extracted data.
Pandas, PyMuPDF, and openpyxl for working with structured data and supported document formats.
pytest for automated testing.

One important design decision is separating AI interpretation from financial calculations.

An AI model can help interpret inconsistent product descriptions and extract information from quotations. However, totals, discounts, tax calculations, and cost comparisons should be handled by deterministic code, with missing or uncertain values clearly flagged for human review.

The project is intended to run locally on a personal computer, without requiring a paid AI API.

Why Does Open Innovation Matter?

For a tool that processes business quotations, privacy and cost matter.

Small businesses may not want to upload supplier prices, purchasing volumes, or commercial terms to an external AI service. They may also find recurring API costs difficult to justify for an occasional task.

Using open-weight models with local inference makes a different approach possible:

Privacy: documents can be processed locally without sending their contents to a cloud AI API.
Cost control: there is no per-request fee from a paid AI inference API, although hardware and electricity still have costs.
Flexibility: the model can potentially be replaced with another compatible open-weight model.
Transparency: calculations can be implemented and tested in ordinary Python instead of relying on an AI-generated answer.
Accessibility: the goal is to make useful procurement assistance more accessible to smaller businesses, not just large companies with enterprise software budgets.

Open innovation is valuable here because it gives developers the freedom to adapt the technology to a practical business problem while retaining control over data and costs.

My Agent Session

I used Cursor to help develop the project in stages, with an emphasis on modular code, deterministic calculations, and tests for edge cases.

Prize Categories

Gemma: planned local inference using the Gemma family of open-weight models.

Touch Grass Garden Coach: A Local LLM That Tells You What to Plant This Week

Ansh Rajpoot — Sun, 11 Oct 2026 17:03:23 +0000

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

The problem: gardening apps want you on your phone

Every gardening app I tried wanted me to scroll more: feeds, tips, notifications, "community". But the whole point of a garden is to be in it. The question I actually have on a Saturday morning is tiny:

What should I do outside this week?
The answer depends on one boring, very local fact: your frost dates. Tomatoes go out about a week after the last spring frost, and garlic goes in a few weeks before the first fall frost. Most people don't know their frost dates, and most apps hardcode a "zone" that may be off by weeks for your exact town.

So I built Touch Grass Garden Coach: type your town and get one short page you can glance at before heading outside.

What I built

Type a place (e.g. Boston) and you get:

Your frost dates, computed rather than looked up. I pull the last 10 full years of daily minimum temperatures for that exact spot, find the last spring frost and first fall frost of each year (min ≤ 0 °C), and take the median.
Plant this week. What to start indoors, sow, transplant or plant right now, with the date each window closes.
Care & harvest. What's ready to pick, what's coming up, and age-based care like "Thin carrots to 5 cm apart" or "Stake or cage tomatoes". Tender crops stop at first frost.
Frost & rain warnings from the 7-day forecast, plus the best day to get outside (the warmest dry day).
"This week outside": a checklist of at most 6 items written by a local open-weight model.

It also has a My garden tab (log what you actually planted, and get progress bars and exact harvest dates) and a Season tab (a 12-month timeline of every crop's windows, with today and your frost dates marked).

For Boston this week, it says: sow fall lettuce, spinach and radish, plant garlic and tulip bulbs, pick the last tomatoes, skip watering on Sunday, Monday and Friday, and go outside on Wednesday (dry, 25 °C).

Why the model runs locally

The checklist is written by Qwen 2.5 1.5B running through Ollama on localhost. There's no hosted AI API, no API key and no account. The weather comes from Open-Meteo, which is free and also needs no key.

I deliberately kept the model's job small. It never decides when to plant. All of that is plain, tested Python. The model only gets structured facts:

{
  "place": "Boston, Massachusetts, US",
  "last_spring_frost": "2026-04-11",
  "first_fall_frost": "2026-11-07",
  "this_week_crops": ["Sow lettuce (fall crop)", "Plant garlic", "..."],
  "ready_to_harvest": ["tomato"],
  "care_tasks": ["Pinch tomato side shoots and tie in stems"],
  "forecast_tips": ["Rain on Mon Oct 12: skip watering"],
  "best_day_outside": "Wed Oct 14"
}

…and turns them into a friendly checklist. That design makes a 1.5B model genuinely useful: it can't invent a planting date, because it never has to work one out. Two small guardrails help too:

Lines mentioning a crop that isn't in the facts are dropped, since small models like to improvise.
Frost and harvest reminders are always kept, even if the model forgets them.
And if Ollama isn't running, the app doesn't break. It shows a rule-based checklist built from the same facts, with a small note: "Local model offline — showing rule-based plan."

Want a different model? OLLAMA_MODEL=gemma2:2b python server.py works with anything you've pulled.

How it works

The whole thing is Python 3.12 standard library only: http.server, urllib, json and statistics. There are no pip dependencies. The frontend is one HTML page and a plain ES module.

The core frost logic is ordinary, testable code:

for year, readings in sorted(by_year.items()):
    july1 = date(year, 7, 1)
    frosts = sorted(d for d, t in readings if t <= 0.0)
    spring = [d for d in frosts if d < july1]   # last one = last spring frost
    fall = [d for d in frosts if d >= july1]    # first one = first fall frost
    ...
last_frost = statistics.median(spring_doys)

A few details I'm happy with:

- Southern hemisphere: Melbourne's winter is in July, so the data is shifted half a year, run through the same logic, and shifted back.

- Frost-free places :(frost in fewer than half the years, like Miami or Mumbai) get approximate anchors that are clearly labelled as such.

- Crop calendar as data: each crop is a window in weeks relative to last or first frost, e.g. tomato transplant LF+1..LF+3, garlic FF-4..FF+2.

- Offline after the first lookup: frost history is cached on disk (it barely changes), so the calendar keeps working with no internet.

- 35 unit tests: fully offline, using synthetic temperature data for northern, southern and frost-free locations, plus the care and harvest logic.

Try it yourself

# optional, for the AI-written checklist
ollama pull qwen2.5:1.5b

python server.py          # http://localhost:8000
python cli.py "Boston"    # same plan in the terminal

Why open matters here

A closed API could write the same six sentences. But a garden coach knows where you live and what you grow, and none of that needs to leave your laptop. With an open-weight model:

1.It runs locally, so your garden data stays on your machine.
2.There are no API keys and no cost, and nothing to sign up for.
3.You can swap any open model with one environment variable.
4.You can inspect everything: the prompt, the facts the model sees, and the rules that decide what's in season.

For a tool whose whole goal is getting you off the screen, that feels right: a small model quietly does its job on your laptop, then gets out of the way.

What I'd build next

1.Soil temperature from the forecast (great for bean and corn timing)
2.Succession reminders like "sow another row of lettuce"
3.Exporting the season as a calendar file to put on the fridge
4.Measuring whether people actually go outside more, rather than how long they spend in the app

For now, it has one job: tell you what to do in the garden this week, then send you outside.

Would love to hear your suggestions on this! What features or improvements do you think I should add next? Feel free to point out anything that could be better 👀

Ansh Rajpoot — Sat, 03 Oct 2026 14:06:07 +0000

Hacktoberfest: Maintainer Spotlight

Ansh Rajpoot

Oct 3

ScamCheck: Investigate the Message, Not Just the Sender — Built for My Scam-Prone Friend

#devchallenge #hacktoberfest #security #hf26challenge

3 min read

ScamCheck: Investigate the Message, Not Just the Sender — Built for My Scam-Prone Friend

Ansh Rajpoot — Sat, 03 Oct 2026 13:55:28 +0000

devchallenge #weekendchallenge #hf26challenge

Hacktoberfest Weekend Challenge: Build for a Friend 🤝**

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

What I Built

I built ScamCheck for a friend who regularly receives suspicious bank, KYC, delivery, payment and account-warning messages and usually asks me:

GitHub: github.com/ansh-rajpoot/scamcheck

"Is this real or a scam?"

The problem is that simply asking an AI chatbot isn't enough.

A chatbot can confidently say "this looks like a scam", but that doesn't tell you why, what can actually be verified, or what is still unknown.

So I built something different.

ScamCheck investigates the message and shows the evidence.

Paste a suspicious SMS, WhatsApp message, email, or URL and ScamCheck breaks it into:

suspicious signals it directly observed
organizations and claims mentioned in the message
URLs and domains
external evidence found through web search
things that could not be verified
safe next steps

The AI doesn't get to invent evidence or blindly decide the answer.

How it works
DEMO

The result looks more like a security investigation than a chatbot:
Suspicious signals found
Observed: "Your account will be blocked today"
Observed: OTP requested
Claimed organization: SBI
External evidence: relevant official/public source
Unverified: sender identity
Recommended action: don't share the OTP; verify through the organization's official website/app instead.

There is deliberately no arbitrary "87% scam" score.

Evidence should be explainable, not a number invented by an LLM.

Why Local AI?

Scam messages can contain extremely sensitive information:

- bank details
- account suffixes
- phone numbers
- transaction information
- names
- addresses
- payment information **

ScamCheck uses **Gemma 3 4B **through Ollama, so the AI analysis can run locally on the user's machine.

The entire private message doesn't need to be sent to an AI API just to understand it.

When external verification is useful, ScamCheck sends a minimal search query rather than the complete private message.

That's the part of open-weight AI that mattered to me: the user can actually keep the core analysis at home.

_**Why not just use an LLM?

Because an LLM shouldn't be trusted with facts it can determine more reliably using normal code.
**_
For example:

"Enter your OTP immediately"

can be detected deterministically.

So can:

https://example.com/login

Gemma is then used for the parts where language understanding is useful:

extracting claims
identifying claimed organizations
understanding requested actions
structuring the investigation

External search provides another layer of evidence.

The final report keeps those sources separate.

The Friend Test

The real test isn't whether ScamCheck produces a clever AI response.

It's whether my friend can paste a suspicious message and understand:

"What exactly is suspicious here, what was actually verified, and what should I do next?"

That's what I built it for.

Tech Stack

*Python
FastAPI
HTML/CSS/JavaScript
Ollama
Gemma 3 4B
SerpApi
*
The application runs locally, with the browser communicating with a local FastAPI server.

Open Source AI

The core AI runs through an open-weight model rather than requiring a proprietary hosted model for the analysis.

That means the model can be:

run locally
swapped for another open model
inspected and controlled by the developer
used without sending every private message to a third-party AI API

For a tool dealing with potentially sensitive messages, that difference matters.

What I Learned

The biggest lesson was that AI should not be the entire security system.

The useful architecture turned out to be:

deterministic code + local AI + external evidence

rather than:

send everything to an LLM and trust its verdict.

That made ScamCheck both more explainable and more useful.

Limitations

ScamCheck cannot guarantee that a message is legitimate or fraudulent.

External search results are evidence, not absolute proof.

It also does not automatically access WhatsApp, Gmail, Telegram, or other private accounts, and it does not automatically open suspicious URLs.

The goal is to help a person investigate safely—not pretend that an AI can know everything.

Prize Categories

Gemma — Best Use of Gemma

SerpApi — Best Use of SerpApi

DEV Community: Ansh Rajpoot

Lazy Notes: Let Local AI Do the Reading for You

What I Built

Demo

Code

ansh-rajpoot / lazy-noted

How I Built It

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

The Cheapest Supplier Wasn't Actually the Cheapest — So I Built QuoteDiff with Local AI

What I Built

Demo

Code

ansh-rajpoot / quotebot

QuoteDiff

macOS setup

1. Prerequisites

2. Start Ollama and download the model

How I Built It

Why Does Open Innovation Matter?

My Agent Session

Prize Categories

Touch Grass Garden Coach: A Local LLM That Tells You What to Plant This Week

The problem: gardening apps want you on your phone

What I built

Why the model runs locally

How it works

Try it yourself

Why open matters here

What I'd build next

Would love to hear your suggestions on this! What features or improvements do you think I should add next? Feel free to point out anything that could be better 👀

ScamCheck: Investigate the Message, Not Just the Sender — Built for My Scam-Prone Friend

ScamCheck: Investigate the Message, Not Just the Sender — Built for My Scam-Prone Friend

devchallenge #weekendchallenge #hf26challenge

Tech Stack

Open Source AI