DEV Community: Vivek Shah

The tea stall granny next to my office runs on UPI, so I built a payment announcer that speaks Hindi

Vivek Shah — Tue, 20 Oct 2026 11:08:03 +0000

Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady Submission 🦥

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

Amma's rush hour

Next to my office there is a small tea stall. We call the woman who runs it Amma (Mother). By my rough count, on a normal day she sells about 100 cups of tea at ₹15 a glass, about 150 pieces of murukku at ₹5, about 100 bananas at ₹10, and about 75 samosas at ₹15 each - somewhere around ₹4,400 a day, across a counter the size of a desk.

Almost all of it is UPI now - about 95%. She prefers it that way: few customers carry exact change these days, and she does not keep change to give back.

The hard part is the checking. She is not very hands-on with her phone, and when you are serving tea and snacks all day, your hands are not clean. Every time a payment should have arrived, she has to stop, wipe her hands, pick up the phone, and read the SMS list to see whether the money actually came - and whether it came in the order she expects, so she can match payments to the people standing in front of her. At rush hour there are five to ten people at the counter at once. That is when it breaks.

Shops solve this with a soundbox, the little speaker that announces every payment out loud. A commercial one costs more than a stall this size can justify. So she wipes her hands and checks the phone.

This week's theme is Slow and Steady: build something that does the work so you don't have to. So I built the part she actually needs.

What I Built

A payment announcer that started on a laptop (as a POC) and now also runs as an Android app, speaking Hindi:

It takes payment SMS as they arrive and parses them with strict rules - amount, sender, reference, time. Only a genuine success credit counts. Refunds, failed transactions, payment requests, outgoing debits and OTPs are not counted as sales.
The moment a real payment lands, it says so out loud in Hindi. A ₹250 credit is announced as "₹250 प्राप्त हुए" ("₹250 received"), and when the SMS names a payer it says "Suresh से ₹5,000 प्राप्त हुए". The voice is Piper, an open-source voice that runs offline. She never touches the phone.
At closing time, one button produces a spoken end-of-day summary in Hindi plus a bills and due-dates list. The summary is written by Gemma 3 (4B) running locally through Ollama. If the model is not running, a plain template steps in, so the demo can never die on stage.

Judges cannot stand at her stall, so the demo looks like her phone: a phone-sized screen in the browser where SMS drop in like notifications, the payment shows as a big card, and one button feeds in a fake SMS - including the nasty ones. A spoofed sender, a refund, an OTP message: you can watch each one get rejected.

The safeguards are the point, not a footnote:

Only senders on her allowlist are even read. An unknown sender is not counted and the app says why.
OTPs, links and bank balances are never spoken or shown. The balance in an SMS is parsed for the record and kept out of everything else.
Repeat SMS are deduplicated by reference number. When a bank format has no reference, a match on amount plus time is flagged for review instead of announced as fact.
Large amounts (₹2,000 and up) are announced with "verify in your bank app".

Real numbers from my test runs: the demo feeds 16 sample SMS through the parser. 8 are counted, 4 are rejected outright (a payment request, a debit, a failed payment and an OTP), 1 refund is recorded separately, 1 spoofed sender is flagged for review, and 2 duplicates are flagged without being counted a second time. The counted total is ₹5,716, and the ₹5,000 payment gets the large-amount warning. All 41 Python unit tests pass; the Android port now adds 71 Kotlin tests.

Demo

Video walkthrough: https://youtu.be/rqhXEc9zLs8
Screenshots: the phone frame with a ₹5,000 payment announced, and a failed payment shown as not counted.

Run it yourself:

git clone https://github.com/viveknshah/payment-announcer
cd payment-announcer
python app.py demo # 16 sample SMS, 8 counted, spoken aloud
python app.py serve # phone-frame UI on http://localhost:8000
python test_suite.py # 41 unit tests

Python 3.10 or newer. Nothing to pip install.

No hosted demo, on purpose: it is built to run on one machine with nothing sent anywhere, so the demo is the repo plus the video.

Code

https://github.com/viveknshah/payment-announcer

How I Built It

Plain Python, boring on purpose. The standard library only, no pip install. Piper (voice) and Ollama (summary) are optional extras.

The parser is rules, not a model. Bank SMS wording changes often enough that I trust code I can read over a model I cannot, and amounts are stored in paise as integers, so ₹15.00 never becomes 14.999. The rules follow two real Bank of Baroda SMS layouts - one UPI credit alert with a 12-digit reference, one plain credit with only an amount and a date. Every name, account number, reference and amount in the repo is fictional. No real message text is in it.

The voice is Piper with the hi_IN-pratham-medium voice: open-source and offline, with the operating system voice or plain text as fallback. The voice files are not in the repo (about 60 MB).

The end-of-day summary comes from a local Gemma model (Gemma 3, 4B) through Ollama's API. The model only gets the day's parsed numbers, never the raw SMS text. The division of labour is the same rule I used in my last project:

Measured in code (facts)	Judged by the model (words)
Today's total and payment count	How the summary is phrased
Duplicate and uncertain matches	Which pending items to mention first
Bill due dates from bills.json	The reminder wording

Small models drift on money, so the summary cannot lie about it. The model's text is spoken only if every rupee amount matches the ledger, the exact total appears in digits, and no English wrapper text survives. Otherwise the template is spoken. The bills line always comes from bills.json, never from the model.

Languages are JSON packs. Hindi is complete. English and Kannada are stubs for now, and they run on templates so the demo still works.

Python: 41 unit tests, all passing. Android v0.2: 71 Kotlin tests, all passing.

Prior art, honestly: UPIPaymentAlert already parses Indian payment SMS and speaks them, and every payment company sells a soundbox. What this adds is the part after the beep: a summary that closes her day with the bills list, and language packs, so the next stall over can have Kannada without asking anyone's permission.

Others are working the same street this week, which is a good sign: Gazette turns any notification into a ledger with Gemma 1B on the phone, Kharcha reads Indian bank SMS with a 4B model on a laptop, and khata keeps a household ledger. None of them speaks each payment out loud in Hindi or closes the day with the bills list; that is the gap this fills.

Why Does Open Innovation Matter?

Her SMS are her income. The parser, the voice and the model are all designed to run on the device, and nothing is sent anywhere.
The cost has to be zero. A stall that sells ₹15 tea cannot pay a monthly fee to hear its own money arrive. Open weights and an open-source voice make the running cost nothing.
Nothing is locked. The model is one line in config.json, the bank formats are readable rules, and a new language is a JSON file. When a better open model fits the laptop, the upgrade is changing a string.

My Agent Session

The full build session, including the failed Gemma 4 load and the guard that catches a wrong total:

Chai Stall Pay Announcer: Hindi voice, a 4B Gemma summary, and a total that can't lie

You

Finish the Week 3 Hacktoberfest project "Chai Stall Pay Announcer" (payment-announcer) and get the web demo running with Hindi voice and Gemma summaries for a clean recording. Fix defects as you go.

Agent

Unpacked the 16-file, stdlib-only app and verified it against its own README: 34 tests green, demo counted 8 payments for Rs 5,716, excluded the decoys, kept the refund separate, flagged the spoofed sender and the Rs 5,000 payment as LARGE.

▸ shell python test_suite.py; python app.py demo --no-speak

Input

$ python test_suite.py; python app.py demo --no-speak

Output

Ran 34 tests in 0.29s OK
8 CREDITED / 4 EXCLUDED / 1 REFUND / 1 REVIEW / 2 DUPLICATE
total 5716

Agent

First real defect: on Windows the console crashed with UnicodeEncodeError (cp1252) the moment a Devanagari announcement was printed. Added force_utf8_stdio() in app.py and server.py, then verified console, redirected output and the HTTP path. Also fixed stale UI state: the summary box now clears when the ledger changes, the last-payment card hides on undo, and /api/undo resets last_record and announces undo_done.

▸ edit app.py: add force_utf8_stdio() and call it from main(); server.py: call it fr...

Input

app.py: add force_utf8_stdio() and call it from main(); server.py: call it from serve()

Output

Devanagari now prints correctly to console, pipes and the web UI

Agent

Local model: gemma4:e4b did not exist (404 from /api/show), so I pinned the installed gemma4:latest. Gemma 4 is a thinking model, and without "think": false it burned the whole token budget on hidden reasoning and returned an empty response, which silently fell back to the template.

You

run all the tests so it can be recorded for the demo at ease

Agent

Made the engine reporting honest instead of optimistic: ollama_available() now checks that the configured model actually appears in /api/tags, so the footer only says "Gemma via Ollama" when it is true. Tightened the summary too: English/meta lines stripped, rupee amounts checked against the ledger, model skipped when there are no payments. Tests went 34 to 38.

Agent

Windows only ships en-US SAPI voices, so Hindi was garbled. Installed Piper with hi_IN-pratham-medium.onnx and verified the app path returns mode "piper" (1.6 s of audio, real-time factor about 3 on this CPU).

▸ shell piper/piper.exe --model voices/hi_IN-pratham-medium.onnx --output_file test.wav

Input

$ piper/piper.exe --model voices/hi_IN-pratham-medium.onnx --output_file test.wav

Output

mode: piper, 1.6s wav

You

the app is not keeping up with the voice commands ... I have stopped the recording as the demo got messed up ... clear out the screen

Agent

Found the cause: every feed request spawned its own speech thread, so five quick clicks produced five voices at once and the demo fell behind. Replaced it with one narrator thread and a maxsize-1 queue where the newest line wins, plus a real speaking flag for the UI dot. Rapid clicking now drops stale announcements instead of queueing them.

▸ edit server.py: DemoState speech queue (maxsize=1), _speech_worker, RLock, seq-bas...

Input

server.py: DemoState speech queue (maxsize=1), _speech_worker, RLock, seq-based pending state

Output

One voice at a time; stale lines dropped; speaking reflects actual playback

You

when do I hit the record button?

Agent

While warming the model I hit a hard failure: gemma4:latest (7.5B) needs a 6,028,115,264-byte CUDA_Host buffer and this machine had ~5.5 GB free of 15.7 GB. Ollama returned HTTP 500 after hanging for 190 s, twice. Not something to gamble on during a take.

▸ shell curl -X POST localhost:11434/api/generate (gemma4:latest, num_predict 2)

Input

$ curl -X POST localhost:11434/api/generate (gemma4:latest, num_predict 2)

Output

500 after 190.2s: llama-server reported out-of-memory during startup: failed to allocate buffer of size 6028115264

Agent

Switched the demo to gemma3:4b (4.3B, 2.9 GB) with num_gpu 0 and keep_alive 30m so Ollama does not unload between takes. Cold load is 1-3 minutes; a summary takes about 40 s on CPU, which the UI covers with a waiting state. Updated config, README and the honesty notes: it is Gemma 3 4B, not Gemma 4 7B.

Agent

The smaller model exposed a bug worth more than the feature: it once said "पाँच हजार सात सौ सत्रह" (5,717) for a 5,716 total, which no digit check could catch, and once ignored the facts entirely and wrote a greeting. Fix: the answer must contain the exact total in digits, plus a one-line Hindi example in the prompt. Otherwise the deterministic template is spoken. Tests now 41.

▸ shell python app.py demo --no-speak (after prompt + guard change)

Input

$ python app.py demo --no-speak (after prompt + guard change)

Output

summary engine: gemma
आज 8 भुगतान मिले, कुल ₹5,716। दस बजे का समय सबसे व्यस्त था, अभी एक संदेश जाँचने बाकी।

You

check into github repository under the project account

Agent

Created and pushed the repository (public, 2 commits, 18 files). .gitignore excludes the 60 MB of Piper binaries and voices, runtime ledger, logs and pycache, so the repo is source-only. Added a rendered README.md with the honest limits, and set topics. No credentials are stored in .git/config or in this transcript.

▸ shell git init -b main; git add -A; git commit; git push origin main

Input

$ git init -b main; git add -A; git commit; git push origin main

Output

new branch main -> main
8056691 Add rendered README for the GitHub landing page

You

I am done recording. you can close gemma

Agent

Unloaded the model with keep_alive 0 (api/ps empty), stopped the demo server so port 8000 is closed, and confirmed the repo is clean at 8056691. Outstanding security item: rotate the credentials used during the session.

▸ shell curl -X POST localhost:11434/api/generate {model: gemma3:4b, keep_alive: 0}

Input

$ curl -X POST localhost:11434/api/generate {model: gemma3:4b, keep_alive: 0}

Output

unload: 200 in 0.006s
{"models":[]}

You

has the session made it to devrelay?

Agent

No — the session list showed only older, unrelated sessions. Nothing from this build existed on DEV, so this transcript is the first submission, created unpublished so it can be reviewed before sharing.

▸ shell devrelay sessions list

Input

$ devrelay sessions list

Output

Older sessions were present, but none from this build.

The Lazy Payoff

She serves tea; the phone does the checking. No wiping hands, no scrolling through SMS with five people waiting, no mental arithmetic at closing time. The announcements just happen, and at the end of the day one button sums it up and lists the bills that are due.

The soundbox companies built this for shops with margins. This is the sloth version for a stall that sells ₹5 murukku: it does the work, she does not have to, and it costs her nothing to keep.

Update: the Android app is built (v0.2)

The Week 3 entry was the laptop proof. Since publishing it, I finished the native Android port I said was next.

The parser and ledger are pure-JVM Kotlin modules, with a field-by-field parity test against the Python parser on the same 16-message corpus.
Room stores the ledger. Daily stats, undo, and a 120-second cross-source dedupe window are in place, so a bank SMS and the matching GPay/PhonePe notification are counted once.
A NotificationListenerService handles payment-app notifications. The sideloaded foss flavor adds RECEIVE_SMS; the play flavor stays notification-only.
System Hindi TTS uses a single latest-wins queue, so announcements cannot overlap. If Hindi is missing, the app reports it instead of silently falling back to English.
The app includes notification-access and SMS onboarding, a foreground watchdog, a boot receiver, a spoken day summary, and undo.
71 JVM/Robolectric tests pass. The release builds are signed and neither APK requests the INTERNET permission.

What is not done: I have only run it on an emulator. There, the SMS → ledger → TTS path worked for a bank SMS, and the TTS engine requested audio focus. I have not listened to the Hindi voice on a real phone, tested a real bank's live notification stream, or done a reboot/OEM battery soak. The notification listener and SMS receiver are a working implementation, not a certified one. A physical-phone pass is the next gate.

One intake detail worth calling out: Google Messages often shows a bank display name such as "Bank of Baroda" rather than the SMS sender token. The app maps known display names to the parser's token, and ignores unrecognised personal conversations instead of turning them into review rows.

Code and install notes: android/README.md and docs/install.md.

What's honestly rough

This started as a laptop demo. The Android v0.2 app now exists (see the update above), but it has only been run on an emulator. I have not tested a real phone, a real bank's live notification stream, reboot behavior on an OEM build, or the Hindi voice through a phone speaker. The web page is still a simulator; the laptop's real input path is python app.py watch fed by an SMS forwarder.
The parser is tested on fictional fixtures plus two Bank of Baroda layouts with fake values. Other banks word their SMS differently and will need their own rules.
A bigger model did not fit. gemma4:latest (7.5B) needs about 6 GB free and failed with an out-of-memory error on my 16 GB laptop, so I run gemma3:4b on CPU. A summary takes about 40 seconds, and the screen shows a waiting state.
Gemma 3 4B drifted on money in my testing: once it said "5,717" for a 5,716 total, and once it ignored the facts entirely. That is why the guard above exists.
Rapid taps used to start one speech thread per message, so the voices overlapped and the app fell behind. The demo now has a single narrator queue where only the newest line survives.
Only Hindi has a full voice pack. English and Kannada are template stubs.

Prize categories

Entering the overall judging and Best Use of Gemma: a local Gemma model (Gemma 3, 4B, through Ollama) writes the end-of-day summary, checked by code against the ledger.

I am competing in a Table Topics contest, so I built myself a coach that scores like a real judge

Vivek Shah — Fri, 16 Oct 2026 18:37:01 +0000

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

The problem

Table Topics is the impromptu round of Toastmasters: you get a prompt you've never seen, and you stand up and speak for one to two minutes. No notes, no prep.

I'm competing soon, and my weakness is exactly that - I ramble, I overrun the time, and I can't hear my own filler words. A human coach costs money per session and can't sit with me at 11pm the week before a contest. The feedback tools that exist want my audio on their servers and charge per minute, which is exactly wrong for daily drills.

So I built Confident Speaker Coach: open a link, get a topic, speak, and get scored on the actual Toastmasters ballot - Content 55, Delivery 30, Language 15 - plus one audience-member's honest reaction, the single biggest fix, and one concrete upgrade. The coach reads the verdict back to me out loud.

Demo

Video walkthrough: https://youtu.be/bNixwmELWNo - one full round: the topic 'What is overrated, and what is underrated?', a real 2:01 speech, and the coach's scored verdict.
Source: https://github.com/viveknshah/confident-speaker-coach

No hosted demo, on purpose: the whole point is that it runs on your machine, so the demo is the repo plus the video. It takes one command:

Run it yourself

git clone https://github.com/viveknshah/confident-speaker-coach
cd confident-speaker-coach
docker compose up        # pulls qwen2.5:3b-instruct (~1.9 GB) on first run
# open http://localhost:3000 - Chrome or Edge for the mic

No Docker? ollama pull qwen2.5:3b-instruct && node server.js - Node 18+, zero npm dependencies. Swap the model with OLLAMA_MODEL (I used gemma3:4b for a while). Once the model is pulled, the coaching loop runs locally - note the typed fallback is the fully-offline input path; Chrome's live transcription uses the browser's speech service.

What it does

Gives you a Table Topics prompt.
Runs a contest timer with the official 1:00-2:30 window, and transcribes your speech live in the browser (Web Speech API; typed fallback in other browsers).
Scores the speech: the app measures length, words per minute and filler words in code - those are facts, and I don't trust a model to guess them. A local open-weight model judges the content, structure and language, and its ballot scores get clamped to the real 55/30/15 weights.
Tells you the verdict the way my club's coaches do: length first, then the ballot, then how it landed for an audience member, then the one biggest fix and one concrete upgrade for your next attempt.
Speaks a 3-sentence verdict back out loud, so practice feels like a person is in the room. It uses the browser's built-in voice by default; set an ElevenLabs key and it upgrades to a natural voice, with the key kept server-side.

The open-source AI at the core

The coach is an open-weight model - qwen2.5:3b-instruct - running in Ollama on the server. Remove it and the product is a kitchen timer. Every part of the feedback that requires judgment (ballot scoring, the audience reaction, the fix, the rewritten beat) comes from that model, constrained to strict JSON so the UI can render it directly.

Why a 3B model: it's small enough for a cheap 4 GB CPU box, and it's reliable at structured output for its size, which matters because the UI renders the fields it returns. Don't like my choice? OLLAMA_MODEL=gemma3:4b docker compose up - the whole coaching brain is one environment variable.

The division of labour is deliberate:

Measured in code (facts)	Judged by the model (opinion)
Speech length vs the 1:00-2:30 contest rule	Content and structure quality
Words per minute	Language and word choice
Filler-word counts	Audience reaction, biggest fix, one upgrade

Small models are generous graders. Mine can't inflate the numbers, because the numbers come from a stopwatch and a word counter.

Why open innovation is what makes this work

Cost is why the business works. Unlimited practice is the product. A club of 30 members running 10 drills a week each is thousands of model calls a month - free on open weights, a growing invoice on a per-token API. The subscription math only closes at zero marginal cost.
Privacy is a feature, not a compliance line. Table Topics speeches are personal - people talk about their jobs, their families, their failures. On a self-hosted club instance, the transcripts and scores never leave infrastructure the club controls. (One honest caveat: if you use the mic, Chrome's live transcription uses the browser's speech service - the typed fallback keeps everything on the box.)
No lock-in. The model, the prompt and the scoring rules are all in the repo. A club can fine-tune for its own contest format, swap models as better open weights land, and never renegotiate with me or anyone else.

Who pays

Toastmasters has over 265,000 members across 13,800+ clubs, and every one of them practices Table Topics weekly with no good way to get feedback between meetings. Clubs pay a monthly subscription for the hosted version - shared practice, member progress, their own topics. Individuals self-host free; the whole thing is one docker compose up, because the people who most need speaking practice are often the people least able to pay per session.

First user: me, the night I built it. I gave it a real Table Topics attempt - "What is overrated, and what is underrated?" - and rambled for two minutes about movie hype. The coach scored me 28/100 and it was right: it clocked my 37-words-per-minute crawl (I was thinking, not speaking), called the speech disjointed, and its one fix was "define overrated vs underrated up front, then structure around it." That's exactly what a human evaluator would have told me, at 11pm, for free, with the audio never leaving my laptop.

How it's built

Zero-dependency Node 18 server (no npm install), static frontend, Docker compose with Ollama and the model pull baked in:

Browser (mic, live STT, timer) --> Node server --> Ollama (qwen2.5:3b-instruct, strict JSON)
                                    |
                                    +--> optional ElevenLabs TTS (browser voice by default)

/api/topic, /api/coach, /api/speak (optional rate-limited ElevenLabs proxy; browser voice when unset). Tests cover the timing rules, filler measurement, score clamping and the API in mock mode.

What's honestly rough

A 3B model is a decent club coach, not a world champion judge. The measured facts keep it honest; the prose feedback is where bigger open models (or a fine-tune on real ballots) would help.
Live transcription uses the browser's Web Speech API, so Chrome/Edge only for now - swapping in local Whisper is the obvious next step, and it's open-weight too.
What broke in my real run: this laptop's Ollama GPU runner was broken - every coaching call failed with CUDA error: shared object initialization failed - so the verified setup is a CPU-only Ollama server. Related: gemma3:4b on CPU managed ~1.3 tok/s (a verdict would take 6+ minutes), which is why the demo ships qwen2.5:3b-instruct (~3 tok/s warm, ~3 min per verdict - the video captions the thinking pause instead of editing it out).

My Agent Session

Confident Speaker Coach: CPU-only run and end-to-end verification

You

Run the Confident Speaker Coach runbook Part 1: run it on the laptop (repo https://github.com/viveknshah/confident-speaker-coach).

Agent

Checked pre-reqs: Docker 29.7.2, Ollama 0.40.3, Node 24 available; installed Git 2.55 via winget, cloned the repo. Zero-dependency Node app, tests 4/4 pass.

▸ shell docker --version; ollama --version; node --version; git clone repo; node --te...

Input

$ docker --version; ollama --version; node --version; git clone repo; node --test test/*.test.js

Output

Docker 29.7.2, Ollama 0.40.3, Node v24.19.0; tests 4 pass, 0 fail

Agent

Started the coach with the already-pulled gemma3:4b. Every /api/coach call failed: Ollama 500 CUDA error shared object initialization failed. The desktop app's GPU runner is broken on this machine.

▸ shell OLLAMA_MODEL=gemma3:4b node server.js; POST /api/coach

Input

$ OLLAMA_MODEL=gemma3:4b node server.js; POST /api/coach

Output

502 Bad Gateway; server log: Ollama 500 CUDA error: shared object initialization failed

Agent

Quit the Ollama tray app, started a CPU-only server with OLLAMA_NUM_GPU=0 and pulled the repo-default qwen2.5:3b-instruct (1.9 GB) in the background. Gemma on CPU managed only 1.3 tok/s, too slow for a coaching verdict.

▸ shell OLLAMA_NUM_GPU=0 ollama serve; ollama pull qwen2.5:3b-instruct; chat speed pr...

Input

$ OLLAMA_NUM_GPU=0 ollama serve; ollama pull qwen2.5:3b-instruct; chat speed probes

Output

qwen pulled; gemma3:4b 1.3 tok/s on CPU, qwen ~3 tok/s warm

Agent

Full end-to-end coaching round through qwen: 301-word Table Topics speech, 85 s. Returned 61/100 (C35/D11/L15), honest mid-range scoring with code-measured facts (212 wpm fast, fillers mapped, delivery penalties applied). Took ~3 min warm, so the demo captions the thinking pause. Page verified in browser with zero console errors.

▸ shell POST /api/coach full transcript; browser snapshot + console check

Input

$ POST /api/coach full transcript; browser snapshot + console check

Output

scores C35/D11/L15 total 61; length 1:25; footer Model qwen2.5:3b-instruct; no JS errors

Prize Categories

Entering overall judging only. ElevenLabs stays in the code as an optional voice upgrade, but the demo ships on the browser voice - no partner category claim.

Built with Ollama + qwen2.5.

TreeTrail: Bengaluru Tree Walks Curated by Local Gemma

Vivek Shah — Wed, 07 Oct 2026 17:43:28 +0000

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

What I Built

Most apps that tell you to go outside start with a goal:

Walk 5,000 steps. Burn 300 calories. Hit your daily target.

I wanted to try something different.

What if the reason to walk was simply:

Go find these five trees.

So I built TreeTrail — a small walking app built around Bengaluru's public tree data.

It takes a tree census, puts the trees on a map around you, lets you tap them for local-AI trivia, and turns a handful of trees into a short exploration loop you can save or export as GPX.

No fitness score.
No leaderboard.
No gamification.

Just a map full of trees and a reason to go look at them.

The surprising part: there are a lot of trees

The starting point is the BBMP tree census.

For the current South Zone snapshot, I bundled the January 2025 public-domain dataset directly into the app. It contains 72,456 mapped trees across the dataset.

When you open a small pocket around Basavanagudi, TreeTrail can find thousands of trees.

For the initial view, I show the 450 nearest.

That little counter — 450 shown / 6,850 found — ended up being one of my favorite parts of the demo.

It makes the density of the city visible.

These aren't abstract numbers in a spreadsheet anymore. They're dots you can actually go and look for.

The basic loop

The flow is deliberately simple:

Pick a pocket → explore trees → choose a few → curate a loop → walk it.

For example, start in Basavanagudi.

The map fills with nearby trees.

Tap one.

Instead of getting a giant botanical database entry, you get a small piece of context generated locally by Gemma 3 4B running through Ollama.

Then add another tree.

And another.

Maybe five is enough.

Hit Curate loop.

The model orders your selected stops into a compact exploration loop.

Save it.

Or export the GPX and take it with you.

The point isn't to optimize the perfect route.

It's to give you a reason to leave your screen.

A walk with something to notice

There's another small feature that matters more than I expected.

At each stop, TreeTrail gives you an observation prompt.

Look at the leaves.

Compare the bark.

Notice the shape of the canopy.

Look at the tree next to it.

That changes the nature of the walk.

You're not just accumulating distance.

You're paying attention.

A 20-minute walk suddenly has a little mission attached to it:

Can you find the five trees?

And when you get there, you actually have something to look at.

The AI is intentionally local

One of the reasons I built this this way was to see how much of the experience could happen locally.

The tree trivia and trail curation run on my laptop using Gemma 3 4B.

There are no hosted inference calls and no per-query AI bill.

That also makes the architecture a little more interesting.

The tree census is local data.

The model is local.

The app can work from the bundled dataset without an API key.

There is still an internet dependency: map tiles come from the internet, and the optional OpenStreetMap mode queries Overpass for live community-mapped data.

I think being explicit about that distinction matters.

"Local AI" shouldn't quietly become "the whole application is offline."

Then I added OpenStreetMap

TreeTrail also has an optional live OpenStreetMap mode for places like Lalbagh, Cubbon Park and Indiranagar.

That gives the app a second, very different kind of open data source.

The BBMP dataset is a civic snapshot.

OpenStreetMap is a continuously editable community map.

And the app labels the source of each tree so you're not left wondering where a particular point came from.

The Lalbagh pocket is particularly fun because the OSM data there is surprisingly rich.

It turns the app into something slightly bigger than a viewer for one government dataset.

You can compare what different open datasets know about the same city.

The data story is the point

I deliberately didn't build an API layer for this prototype.

The BBMP tree census is bundled directly into a Python file.

No API key.

No complicated ingestion pipeline.

No mysterious backend.

You can inspect the source data and see where the trees came from.

That makes the project useful beyond the demo.

BBMP did the work of counting and mapping these trees.

TreeTrail is basically an experiment in asking:

What else can we do with that public data once we make it human-scale?

A spreadsheet can tell you that a tree exists.

A map can show you where it is.

A walking trail can give you a reason to go see it.

The honest limitations

There are a few things I don't want the demo to imply.

First: the generated loop is not walking directions.

It's a straight-line exploration loop.

The dashed lines are a guide for the order of exploration, not turn-by-turn navigation.

Second: the AI's source notes are species-level knowledge phrased by the model.

They're not live research about that individual tree.

If TreeTrail tells you something interesting about a rain tree, that doesn't mean the model has inspected that particular rain tree.

Third: the BBMP data is a January 2025 South Zone snapshot.

It's not a live, citywide inventory.

And some mapped trees may be on private property.

That last one is particularly important.

A point on a map doesn't automatically mean you can walk up to it.

Which brings me to the part I'm most interested in.

I want people to try to break the map

The best test isn't whether the demo works on my laptop.

It's whether someone takes a TreeTrail walk and discovers something the dataset got wrong.

Maybe the "tree" is inside someone's compound.

Maybe it's gone.

Maybe the species note doesn't match what you see.

Maybe the point is technically correct but completely inaccessible.

Or maybe you find an incredible tree you would have walked past a hundred times.

That's the experiment.

Take one walk.

Pick a handful of trees.

Take one photo.

Tell me what TreeTrail got right — and what it got wrong.

Because that's where an open-data project becomes interesting: when the map stops being an artifact on a screen and starts getting checked against the real world.

Demo

Video

Code

[Code Repo]

Vivek Shah / TreeTrail · GitLab

GitLab.com

gitlab.com

How I Built It

TreeTrail is built around a simple idea: use local AI to turn open civic data into something you can experience on foot.

The core dataset is the BBMP tree census — a public-domain snapshot of 72,456 trees from the January 2025 South Zone census. I bundled the data directly into the Python application, so the project doesn't depend on a tree-data API or API keys.

For the AI layer, I use Gemma 3 4B through Ollama, running locally on my laptop.

The model has two small but useful jobs:

Tree trivia — when I tap a mapped tree, the model generates a short species-level note that gives me something to notice when I reach the tree.
Trail curation — after selecting a handful of trees, the model helps order them into a compact exploration loop.

The rest of the application is deliberately straightforward: a map, nearby-tree filtering, stop selection, loop creation, saving, and GPX export.

There's also an optional OpenStreetMap/Overpass mode for places such as Lalbagh, Cubbon Park and Indiranagar. This provides live community-mapped data alongside the bundled BBMP snapshot, with the source clearly identified.

The important part is that the AI isn't trying to replace the map or the data.

The data tells me where to look. The local model gives me something to look for. The walk is where I find out whether any of it is actually true.

And because the inference happens locally, there is no hosted AI endpoint or per-query inference cost sitting behind every tap.

There are still internet dependencies — map tiles load online, and OSM mode queries Overpass — but the core AI experience can run on my own machine.

Why Does Open Innovation Matter?

TreeTrail exists because several pieces of open technology can be connected in ways that weren't possible — or weren't nearly as interesting — as isolated datasets.

The BBMP has already done the hard civic work of counting and mapping trees.

OpenStreetMap provides another layer of community-maintained geographic data.

Ollama makes it practical to run an open-weight model such as Gemma locally.

And open-source mapping and Python tooling make it possible to glue these pieces together without building the project around a proprietary AI platform.

A closed AI API could certainly generate tree trivia and suggest an order for a list of stops.

But the open approach changes the economics and the relationship with the data.

There is no per-query AI bill for every tree someone taps. The model runs on my machine. The tree census can be inspected and bundled with the application. The OSM data can be explored and improved by its community.

More importantly, the pieces remain replaceable.

The dataset can change.

The local model can change.

The mapping source can change.

Someone else can fork the project, use a different city tree census, swap in another open-weight model, or build an entirely different experience on top of the same civic data.

That's what open innovation makes possible here: the project doesn't have to end at the prototype I built.

The BBMP tree census was created as civic data. TreeTrail is one experiment in making that data useful at street level.

A closed API might have helped me build the demo.

Open data and open AI make it possible for someone else to take the idea somewhere I haven't thought of yet.

My Agent Session

TreeTrail local setup and verification

You

Follow instructions in README — run the TreeTrail local tree-walk app.

Agent

Checked environment: no Python on PATH, so installed Python 3.12 via winget and installed the single dependency with pip install requests. Verified treetrail.py compiles (py_compile).

▸ shell winget install Python.Python.3.12; pip install requests; py_compile treetrail.py

Input

$ winget install Python.Python.3.12; pip install requests; py_compile treetrail.py

Output

Python 3.12.10, requests 2.34.2 installed, compile ok

Agent

Confirmed Ollama 0.35.1 already running with gemma3:4b pulled, so no pull needed. Copied treetrail.py into the workspace and started the server on port 8000.

▸ shell ollama list; python treetrail.py --port 8000

Input

$ ollama list; python treetrail.py --port 8000

Output

gemma3:4b present; server up: health ok, census_records 72456

Agent

Verified the census API against README claims: Basavanagudi default returns 6850 total, nearest 450 shown, first record Pongam. Matches the documented South Zone snapshot.

▸ shell GET /api/trees?lat=12.9433&lon=77.5681&source=census

Input

$ GET /api/trees?lat=12.9433&lon=77.5681&source=census

Output

census total 6850, shown 450; first bbmp:GN7530NC6PQH001 Pongam, distance 30m

Agent

Ran one live trivia call and one curated loop with the real gemma3:4b model (README noted this was untested). Trivia returned local-AI phrasing with sources; trail correctly fell back to nearest-neighbor ordering per the ID/detour validator.

▸ shell POST /api/trivia; POST /api/trail (5 stops, 20 min)

Input

$ POST /api/trivia; POST /api/trail (5 stops, 20 min)

Output

trivia mode local AI; trail mode nearest-neighbor fallback, 258m / 14min estimate

Agent

Opened http://localhost:8000 in the browser: title TreeTrail Bengaluru, status shows 6850 mapped records / nearest 450 shown, no console errors. App ready for the 2-minute demo: tap a dot, Pick 5 nearby, Curate loop, Save, export JSON/GPX.

Prize Categories

Table Topics Champion Buddy

Vivek Shah — Sun, 04 Oct 2026 14:35:43 +0000

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

What I Built

I built a local Table Topics practice partner for all my fellow club members (Rishi specifically) to prepare for the upcoming contest season. It give you a Random topic for your impromptu speaking, speak your answer, get a ballot-style scorecard and one concrete recommendation. Open models only, nothing leaves your machine.

Ballot weights: Content 55, Delivery 30, Language 15. Criteria wording is a paraphrase, not official Toastmasters text. Delivery is judged from the transcript only.

Demo

Demo Run Output

Code

Here is the documented code

How I Built It

Everything runs locally through Ollama. An open-weight Gemma model generates a fresh Table Topic and later scores the transcript against the ballot weights (Content 55 / Delivery 30 / Language 15). Open-source Whisper (faster-whisper) handles transcription. No API keys, no cloud calls - a speech you're practicing for a contest stays on your machine, which matters when the material is personal.

Why Does Open Innovation Matter?

A closed API would make every practice session someone else's data and someone else's meter running. Open models mean any Toastmasters club anywhere can run this offline and free - and because the prompts are plain text, a club can tune the scoring to its own ballot without asking anyone's permission.

My Agent Session

Agent Session

Prize Categories

Best Use of Gemma.

Friend's response

Rishi : "Bro, Integrate this with whatsapp! it would make it go viral across the world! If I skip the initial setup, its a gem after that! "

Using MindsDB to Predict Microsoft Stock Prices

Vivek Shah — Mon, 31 Oct 2022 21:01:30 +0000

Ever wanted to be the Oracle like the Delphic one and use it to predict stocks in your portfolio? Can't take to the past but with MindsDB you could take a shot at predicting the future via this simple tutorial.

What is MindsDB?

MindsDB is a SQL-based tool that can be used to create and train time-series machine learning models directly from your database. With MindsDB, data teams and data analysts can use their data to build, train, optimize, and deploy machine learning models that provide meaningful insights for real-world problems.

img source
Setup
Start off with you using the MindsDB Cloud Editor (create your free MindsDB Cloud account here) to create and train your time series prediction model.

Get your Dataset
Download data set from Kaggle for our demo to work with Microsoft stock prices :

Upload your file into MindsDB
You can either load from a database or a file. We'll go with file in this demo.

Check your data
Sanity check your data loads up fine with a simple select query. You can use limit to have only a few records load.

Create a Predictor Model
Tap in the following syntax to get MindsDB to kick off the predictor model. Depending on the volume of data, this could take some time and you might see a "training" error if you query earlier than it is completed.

Data Insights
You can also quickly glean at the data insights generated visually to give you a quick look into the trends for the data sets you have pulled in.

Run a Query for an extrapolated Dates to see the magic
Since our data set is till July 2022, let's try a more recent date like 30th October 2022

With that last step, we have successfully created and trained Using historical data, we can easily try to predict the future. Hopefully my stock broker ain't reading this.

MindsDB makes machine learning simple, intuitive, and extremely effective! Do you have something interesting you’d like to forecast? Head to MindsDB and start training your model today!