DEV Community: Aryan Gupta

KhataLens : A shop’s credit notebook never leaves the shop

Aryan Gupta — Sat, 17 Oct 2026 05:51:55 +0000

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

What I Built

KhataLens turns a photo of a handwritten udhaar notebook page into a clean digital ledger and one-tap WhatsApp payment reminders. It runs entirely on the shopkeeper's own computer.

Walk into a neighbourhood kirana, dairy or medical shop and you will find the same thing behind the counter: a ruled notebook where the owner writes who took what on credit (udhaar) and who paid it back (jama). It is how a lot of small-shop credit works, and it has three problems:

Nobody can answer "who owes me, and how much?" without adding up pages by hand.
Money gets forgotten because chasing it is awkward and nothing prompts it.
The notebook holds your neighbours' names and what they owe. That is not something an owner wants to upload to a cloud service.

KhataLens fixes this without changing the owner's habit. They keep writing in the notebook, photograph the page, and the app:

Reads the handwriting (Hindi and other Devanagari, mixed date formats, Devanagari digits).
Shows every line in an editable table, with suspicious lines highlighted and a reason next to each.
Saves the confirmed lines to a local ledger.
Shows who owes me, filterable by how long since the last entry, and a needs a check view for customers who appear to have paid more than they owed.
Opens WhatsApp with a ready-written reminder in Hindi, Marathi, Tamil or English. Nothing is sent automatically; the owner reviews and sends it.

Who would pay, and how it is a side hustle. The customer is the small shop owner who has years of notebooks and no time to type them in. The service I would sell is setup and digitization: install it on the shop's existing laptop, scan the backlog of pages, set up reminders, and be on call afterwards. My planned pricing is a one-time setup fee of ₹999 and ₹149 per month for support. These are planned prices that I have not yet validated with a shop owner. Because inference is local, there is no per-scan cloud bill eating the margin, and the shop never needs a subscription to an AI provider.

Demo

Code

aryanguptacsvtu / KhataLens

KhataLens

Photograph a handwritten udhaar (credit) notebook page. Get a clean ledger and one-tap WhatsApp payment reminders. Everything runs on the shopkeeper's own computer using an open-weight vision-language model served by Ollama. No customer data leaves the machine.

The app is a plain HTML/CSS/JavaScript web page (no build step, no CDN, works offline) served by a small local Python server that wraps the khatalens package.

Quick start

pip install -r requirements.txt
ollama pull qwen2.5vl:7b          # or any vision model your hardware can run
python scripts/synth_ledger.py --n 20 --out data/synth    # sample pages for the demo
python server.py                  # opens http://127.0.0.1:8000

Click Try a sample page to test the review -> save -> remind flow with no model, or upload / photograph a real page and click Read this page. Use another model with KHATALENS_MODEL=<name> or in Settings (this is where your fine-tuned model plugs in).

Server options:

python server.py

…

View on GitHub

Quick start (from the README):

pip install -r requirements.txt
ollama pull gemma3:4b
KHATALENS_MODEL=gemma3:4b python server.py     # opens http://127.0.0.1:8000
# (Windows PowerShell: $env:KHATALENS_MODEL="gemma3:4b"; python server.py)

How I Built It

The open-weight AI: Gemma 3 4B, Google's multimodal open-weight model, served locally by Ollama. It reads the page image directly and returns the entries as structured JSON. At 4B parameters it is small enough to run on an ordinary laptop, which matters because that is what a shop owner has. I ran it on a Ryzen 5 laptop with 8 GB RAM, about 100-120 seconds per page. The model name is a setting (KHATALENS_MODEL or the Settings drawer), so any vision model Ollama can serve, including a fine-tuned Gemma, plugs in without code changes.

The pipeline around it:

photo -> preprocess -> local VLM -> validate -> human review -> SQLite ledger -> WhatsApp link

Preprocess (OpenCV): resize to a fixed maximum side, even out phone-shadow lighting with CLAHE, and deskew using the notebook's ruled lines. I kept this light on purpose, because heavy binarisation tends to hurt vision models more than it helps.
Structured output: the model is asked for JSON that matches a schema, so the output is data, not prose.
Validation layer: converts Devanagari digits, normalises dates (including missing years), and flags suspicious rows, such as an unreadable amount, instead of silently trusting the model.
Human review before saving: a small 4B model will misread handwriting sometimes, especially smudged amounts and unusual letter shapes. Rather than hide that, the product is built around it: every line is editable, and flagged lines are highlighted.
SQLite ledger: balance is total udhaar minus total payments. Customers are Pending (owes), Settled (exactly zero) or Needs a check (paid more than recorded). Deleting an entry is only allowed in that last view, and the server enforces it.
Reminders: plain wa.me links with message text in four languages. There is no WhatsApp API, no account and no cost.
UI: plain HTML, CSS and JavaScript (no build step, no CDN, works offline) served by a small Python standard-library server on 127.0.0.1. Three themes: Clean, Ledger and Midnight.
Training and evaluation tooling: a synthetic handwritten-page generator that also writes a LLaMA-Factory training file, and an evaluation script that scores field-level accuracy for the base model, a fine-tuned model and a closed API on the same labelled pages.

Results so far. On my own handwritten page (Hindi, mixed date formats), the base model got 6 of 10 lines fully right before review. I have not fine-tuned yet; that is the next step (see below).

A real-world bug that tests missed. My sample pages worked, but the first real notebook photo crashed the server with a NumPy error. The cause was OpenCV's line detector returning a different array shape on my installed version than the one I had coded against. My sample-page mode skips the model and the image preprocessing entirely, so that code path never ran until I tried a real notebook photo. It is a small thing, but it is why the evaluation set has to be real handwriting.

What I would do next:

Fine-tune a LoRA on synthetic pages plus pages in my own handwriting, and test only on handwriting the model has never seen.
Compare base, fine-tuned and a closed API on the same test pages.
Put it in front of a real shop owner.

Building it: I wrote the code with an AI coding assistant (Claude) in a chat session. The shipped product's AI is only the open-weight model running locally; nothing in the running app calls a hosted API.

Why Does Open Innovation Matter?

Three things would not be possible, or would not make sense, with a closed API.

Privacy is the product, not a feature. A udhaar notebook is a list of neighbours and the money they owe. A shop owner will not photograph that and send it to a third party, and I would not want to be the one holding it. With an open-weight model running through Ollama, the photo is never sent anywhere. "Your customers' names and amounts never leave this computer" is a statement I can actually make true.
The economics only work offline. A small shop may scan a few pages a week. A per-call API fee, a subscription, or a dependence on a stable internet connection all break that model. Local inference means the cost of the hundredth page is zero, and the app works when the shop's connection does not. A model as small as Gemma 3 4B is what makes that realistic: it runs on hardware the shop already owns.
I can adapt the model to the handwriting. Handwritten Devanagari, regional shorthand and every shopkeeper's own style are exactly where a general model is weakest. Open weights mean I can fine-tune on pages like the ones I am trying to read, and measure the gain against a closed baseline. With a closed API I could only rewrite the prompt.

Prize Categories

Overall winner, and Gemma (featured category).

Gemma: KhataLens uses Gemma 3 4B, running locally through Ollama, to read handwritten Devanagari ledger pages straight from a photo and return structured entries. Gemma is the only AI in the running app. Its small size is what lets the whole thing run offline on a shop's existing laptop.

TrailBuddy: a local-first AI hiking companion that gets you off the screen

Aryan Gupta — Fri, 09 Oct 2026 13:08:25 +0000

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

What I Built

TrailBuddy is a hiking companion that runs entirely on your own machine. You pick a real trail from your own GPX files, and a local open-weight model gives you a handful of small observation missions and a safety checklist for that trail, such as "listen for three different bird calls" or "find something that is growing on a tree it didn't start on."

While you walk, you tell it what you spotted and it ticks the missions off for you. You can photograph something and get a short description of it. A Touch Grass Score goes up with missions completed, discoveries and time outside, and goes down with screen time. When you finish, the model writes a short first-person journal of the outing and saves it as Markdown and as a shareable HTML report.

The idea is simple: the screen should be the shortest part of the walk. TrailBuddy gives you a reason to look up (a mission), asks you to put the phone away, and only needs a few seconds of screen time to log what you found. It is for anyone who wants a reason to go on a walk or a hike, especially people who want an AI helper without sending their location, photos or journal to a server they don't control.

One design rule I stuck to: the model never invents routes. It only works with real trails you supply as GPX files. The model writes the missions and the journal. The distance, climb and time estimates come from the GPX data.

Demo

TrailBuddy is built to run locally, so there is no hosted link. Setup takes a few minutes and is in the README.

Code

aryanguptacsvtu / Trail-Buddy

TrailBuddy

TrailBuddy is an offline, voice-first hiking companion. It chooses from real GPX trails, suggests short observation missions, answers questions with a local Ollama model, and saves a short journal after the outing.

You can use it two ways:

Web UI (serve.py): a local browser interface with a trail picker, mission tracker, timers, photo scanner, chat and journal.
Command line (run.py): the original voice-first, keyboard-driven mode.

Everything runs on your machine. The browser talks to a small local server, and that server talks to Ollama.

What you need

Python 3.10 or newer
Ollama with a local model
A microphone and speakers for voice mode (command line only)
Optional: a Piper voice model for spoken replies (command line only)
Optional: a vision-capable model such as gemma3:4b for the web UI photo scanner

TrailBuddy does not create or navigate routes. Add GPX files exported from an online route…

View on GitHub

MIT licensed. Python 3.10+, standard-library web server, no frontend framework.

How I Built It

Open-source pieces:

Gemma 3 (4B) through Ollama. This is the model behind everything: it writes missions and safety checklists, answers questions during the walk, works out which mission you've just completed from what you say, describes photos (Gemma 3 is multimodal) and writes the journal. The model name is set by one environment variable, TB_MODEL, so you can swap it for another model such as qwen3:4b.
faster-whisper for local speech-to-text and Piper for local text-to-speech in the command-line, voice-first mode.

How it fits together:

Browser (HTML + CSS + vanilla JS)
   │  JSON over localhost
   |
Python standard-library server (web.py)
   │            │
router.py     llm.py --> Ollama --> Gemma
(GPX → km, climb, minutes)

router.py reads the GPX files and works out distance, elevation gain and estimated time. This is plain code, so the trail facts are never made up by the model.
llm.py is the only part that talks to the model. It has separate prompts for planning, mission detection, replies and the journal, with a shared safety instruction so the model doesn't give risky advice.
web.py is a small http.server app that serves the page and a few JSON endpoints. I deliberately used no web framework and no front-end build step, so the whole project installs with a short requirements.txt.
The same core also powers a command-line mode (run.py) for hands-free use with voice.

Lessons from building it:

Don't leave hard constraints to the model. My first version asked for "what kind of outing" and a time budget, then let the model choose one trail. With a 6-minute budget, no trail fit, so the router quietly fell back to showing all of them, and the model, which was never told the budget, picked a 35-minute loop that matched "moderate fitness." I removed the form. Now every trail is shown as a card, so you choose, and the model only does what it is good at: writing the missions and checklist for the trail you picked. Listing trails needs no model call at all, so it's instant.
Let code do the facts. Distances, climb and times come from the GPX, and the model gets them as input. Small local models are fine at writing and poor at arithmetic.
Be honest about the limits. The photo scanner can be wrong, so the prompt asks for at most two short sentences and an interesting fact only when it is confident. The README also warns people never to use it to identify mushrooms or foraged food.

Current limitations: you need a device that can run Ollama (a laptop for now), trails must come from GPX files you supply, the screen-time meter is manual, and the web UI has no voice input (the command-line mode does). Next steps are a phone-friendly or Raspberry Pi setup and filtering trails by time and fitness.

Why Does Open Innovation Matter?

A hiking app is the kind of tool that should work where the signal doesn't. Open-weight models made three things possible that a closed API wouldn't have:

It works offline. Once the model, the speech model and your GPX files are downloaded, TrailBuddy needs no internet. A cloud API would turn every question on a remote trail into a failed request.
Your data stays with you. TrailBuddy never sends your location, your photos of whatever you found, or your journal to any server. Everything is processed by a model running on your own machine. For an app that knows where you walk and when, that matters.
You can swap and inspect the model. One environment variable changes the model. You can choose a bigger one for better writing or a smaller one for older hardware, and there are no API keys, per-call costs or rate limits to plan around.

It also means anyone can read, change and extend the whole stack: the code is MIT licensed and sits on open models and tools.

Prize Categories

Best Use of Gemma: Gemma 3 (4B), run locally through Ollama, powers every AI feature: mission writing, mission detection from natural language, photo understanding and the journal.

Promise Keeper: Never Forget What You Promised, Even in Hinglish

Aryan Gupta — Sat, 03 Oct 2026 07:22:12 +0000

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

What I Built

Promise Keeper is a small app that remembers what you promised people.

I built it for my friend Amit, who makes a lot of promises in a lot of chats and has forgotten most of them by the end of the day.

The problem isn't making promises. It's that they get buried in messages. A to-do app doesn't help, because nobody stops mid-conversation to write down "told Rahul I'd call tomorrow."

So Promise Keeper works from the message itself:

Paste something you said, in English or Hinglish ("Kal subah main tumhe call karunga"). It extracts the promise, who it's owed to, and the deadline.
Import a WhatsApp chat export. It reads only your lines and finds promises you probably forgot. "Tomorrow" is resolved relative to when you said it, so a promise from last week correctly shows up as overdue.
You confirm everything with date and time pickers before anything is saved.
"What am I forgetting?" gives an honest list: overdue first, then coming up, then no deadline. You can also group by person ("what do I owe Rahul?").
Draft a nudge for an overdue promise: a short, honest "still on it" message you can edit and send.

Demo

🎥 Watch the demo video

I didn't deploy a hosted version on purpose. The app reads private chats, so hosting it would defeat the point. It runs on your own machine in about five minutes (setup is in the README).

Code

aryanguptacsvtu / Promise-Keeper

📝 Promise Keeper

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

A local-first assistant that remembers what you promised people. Paste a message ("I'll send you the report tonight" or "Kal subah main tumhe call karunga"), confirm what it found and later ask "What am I forgetting?"

Open-source core: an open-weight model (Gemma 3) running locally through Ollama, with storage in SQLite. No API keys, no accounts, works with Wi-Fi off. Your messages and relationships never leave your machine.

Run it

Requires Python 3.10+ and Ollama.

# 1. Pull a small open-weight model
ollama pull gemma3:4b

# 2. Install and configure
python -m venv .venv && source .venv/bin/activate      # Windows: .venv\Scripts\activate
pip install -r requirements.txt
cp .env.example .env                                   # Windows: copy .env.example .env

# 3. Start the app
streamlit run app.py

Settings live in .env (git-ignored). No API keys are…

View on GitHub

How I Built It

The AI is Gemma 3 (4B), an open-weight model from Google, running locally through Ollama. The app itself is Streamlit and SQLite. There are no API keys, accounts or remote servers.

A few design decisions matter more than the model choice:

The model never does date maths. Small models are bad at calendars. So the model only copies the phrase ("kal subah", "by Monday"), and plain Python turns it into a real date. That code has 30 test cases, including Hinglish like "5 baje" and "parso shaam".

The "what am I forgetting?" list never comes from the model. It's a database query. A language model asked "what did I promise?" can invent things, which is the worst thing a reminder app can do.

Structured output. The model is constrained to a JSON schema, so I get promises I can parse, not paragraphs.

A human confirms everything. Low-confidence guesses are dropped, and nothing is saved until you check it. Casual chat like "lol nice", "I won't be able to make it" and "if I get time I'll try" should produce nothing, and I wrote test cases for those.

I compared models on 20 labelled messages (13 plain, 3 Hinglish, 4 tricky cases like negation and past tense):

Model	Right # of promises	Deadlines	core	edge	hinglish	Avg s/msg
`gemma3:4b`	17/20	20/20	11/13	3/4	3/3	8.3
`qwen2.5:3b`	18/20	20/20	11/13	4/4	3/3	3.6

The two models are effectively tied. With 20 cases, a one-case gap isn't evidence that either is better. Both got every deadline and every Hinglish message right. Qwen was about twice as fast, which matters when importing a long chat.

Both made the same two mistakes: they treated a request ("Can you send me the notes by tonight?") and someone else's action ("Rahul will send the files tomorrow") as my own promises. Gemma also extracted a past-tense statement ("I sent you the report yesterday"). Since both models fail the same way, I read these as prompt weaknesses rather than model weaknesses, and they're the reason every extraction goes through human confirmation. The test set is small and the timings come from one machine, so treat the numbers as rough.

Why Does Open Innovation Matter?

A promise tracker reads your private conversations: who you talk to, what you owe them, what you've been avoiding. That's about as personal as data gets. Amit shouldn't have to send it to a company's servers to get a reminder.

Open weights made three things possible that a closed API wouldn't:

Nothing leaves the machine. The data stays on the device by design, not by a privacy policy I'm asking you to trust. The demo video shows it running with Wi-Fi off.
It costs nothing to run. There's no per-message bill, so scanning a whole year of a chat export is fine.
Swapping models is a one-line change. The same app runs Gemma, Qwen or Llama by changing a name in the sidebar. That let me measure the models against each other on my own cases instead of accepting what one vendor offers.

There's also a language angle. Hinglish, meaning Hindi written in English letters, is how many people actually text. With open models I can test it directly, and eventually fine-tune for it. That's on my list for next steps.

Prize Categories

Gemma: Gemma 3 4B is the core extraction model, running locally via Ollama. I benchmarked it against Qwen 2.5 on my own labelled cases, including Hinglish.

INTRO

Aryan Gupta — Fri, 02 Oct 2026 05:17:23 +0000

I am new to the community, happy to be part of DEV.

My Socials :
https://github.com/aryanguptacsvtu
https://www.linkedin.com/in/aryan-gupta-27814a306/