DEV Community: Sasmitha Ashinsana

Salli: my bank SMS became a budget while I did nothing 🦥

Sasmitha Ashinsana — Sun, 25 Oct 2026 18:15:56 +0000

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

What I Built

In Sri Lanka, every card swipe, bill payment, salary credit and wallet top-up already sends you an SMS. My phone has years of them. It's a complete record of where my money went and I've never once read it.

Every budgeting app I tried wanted one of two things: type every expense in by hand or hand my bank login to a cloud service. I'm too lazy for the first and too paranoid for the second.

So I built Salli (සල්ලි, Sinhala for money). It reads the money SMS already on my Android phone and turns them into a spending dashboard on my laptop. A local Gemma model does the reading. There's no account and no server and nothing leaves my WiFi.

The whole effort on your side:

Open Salli on your laptop and scan the QR code with the phone app.
Tap Send now.
Go back to being a sloth.

What you get back:

Spent, income and what's left for the month, with transfers between your own accounts kept out of the totals
A daily spend chart with a forecast to the end of the month
Where it went: categories and top shops
Recurring charges found from repeat SMS, with a warning when one goes up
A roast. Gemma writes one cheeky line about your month from your real numbers. It's the feature everyone asks about first.

The phone app does one job: pair, then send.

Screenshots use generated demo SMS. My real spending stays on my laptop, which is the whole point.

Demo

Code

sasmeee / salli

Salli

Your bank SMS become a budget. You do nothing.

Salli reads the money SMS on your Android phone and turns them into a spending dashboard on your laptop using Gemma running locally. No account, no cloud, nothing leaves your WiFi

Demo video · DEV post · Download

Salli (සල්ලි) means money in Sinhala. The mascot is a sloth because the whole point is that you stay lazy.

In Sri Lanka every card swipe, bill payment and salary credit already sends you an SMS. Budgeting apps want you to type all of that in again or hand your bank login to a cloud service. Salli just reads the SMS you already have.

How it works

Android phone                          Your laptop (same WiFi)
┌──────────────────┐   QR pair    ┌──────────────────────────────────────┐
│ Salli app        │ ───────────▶ │ Salli desktop (Tauri + Rust)         │
│ reads SMS inbox  │              │                                      │
│ keeps bank SMS,  │  local

…

View on GitHub

Windows installer and Android APK are on the v1.0.0 release.

How I Built It

Salli is two apps that talk only to each other:

Android phone                          Your laptop (same WiFi)
┌──────────────────┐   QR pair    ┌──────────────────────────────────────┐
│ Salli app        │ ───────────▶ │ Salli desktop (Tauri + Rust)         │
│ reads SMS inbox  │              │                                      │
│ keeps bank SMS,  │  local HTTP  │  1. rules     regex for amounts      │
│ drops OTPs       │ ───────────▶ │  2. memory    shops it already knows │
└──────────────────┘              │  3. Gemma 3   only for new shops     │
                                  │                                      │
                                  │  dashboard · roast · forecast        │
                                  └──────────────────────────────────────┘

The phone is an Expo (React Native) app with a small Kotlin module that reads the SMS inbox. It keeps messages that look like money and drops OTPs on the phone, so they never travel anywhere. Then it posts the rest to the laptop over local HTTP.

The laptop is a Tauri 2 app. A Rust server (axum) listens on port 7777. The UI is React with Tailwind and shadcn/ui.

Gemma does the reading, but only when it has to

I could have sent every SMS to Gemma. On a laptop CPU that would take forever and the slow part of this challenge is supposed to be me, not the app. So reading happens in three layers:

Rules. Regex pulls out the amount and whether it's a debit or a credit. Known formats from Sri Lankan banks get fully parsed here.
Memory. Once Salli knows a shop, it remembers the shop's name and category. If you fix a wrong category, it remembers that too, for every future payment there.
Gemma 3 4B through Ollama, only for SMS the first two layers can't place. One SMS per call, with a strict JSON schema, so the output is always {amount, kind, merchant, category} and never a paragraph.

The first sync of a big inbox is slow, because Gemma meets every shop for the first time. After that, almost everything comes from rules and memory and new SMS show up instantly.

Gemma also writes the roast. It gets a summary of the month (total, top categories, top shops with counts) and a sloth persona prompt with a high temperature. That gives you lines like "Machan, seriously, six times ordering KFC?"

TabPFN for the forecast

The "where your month is heading" number started as a simple average. I swapped in TabPFN, Prior Labs' open tabular foundation model, as an optional upgrade.

Each past day becomes a row: weekday, weekend or not, day of the month and days since the last salary. The target is what I spent that day. TabPFN regresses on that history and predicts the rest of the month, with no training step and no tuning. It picks up that I spend more on weekends and right after payday, which a flat average can't.

It runs as a small Python sidecar that the Rust app calls. On my laptop's CPU, a forecast takes about 8 seconds. If Python or TabPFN isn't installed or there's less than 14 days of history, Salli quietly falls back to the average. Nobody has to install a 900 MB model just to try the app.

Things that went wrong

One payment, three SMS. A single LKR 560 phone bill sent me an alert from my bank, a receipt from the biller and a note from my wallet. That's three "payments". Salli now merges SMS with the same amount within an hour when at least one sender isn't a bank and keeps the bank's row as the main one.
Transfers looked like spending. Moving money to my own savings made my month look terrible. Transfers are now left out of spent and income.
The QR scanner. The Expo camera scanner never focused on my budget Samsung. The Google code scanner crashed on the same phone. I ended up writing a small native module around ZXing and now it scans instantly. It has a red laser line, which I've decided is a feature.
Play Protect blocks sideloaded apps that read SMS. That's fair, honestly. The README explains how to install anyway.

Benchmark

tools/bench.ts generates realistic Sri Lankan bank SMS with known answers and scores what Salli extracts. On that set, amount, direction, shop and category were all correct and every promo and OTP was skipped. Gemma 3 4B takes about 0.6 to 0.7 seconds per new SMS on CPU.

Honest note: some test shops also appear as examples in the Gemma prompt, so real-world accuracy is lower. On my own inbox of about 1,400 SMS, the misses were mostly biller receipts read as income. The duplicate merge now handles those.

Why Does Open Innovation Matter?

Bank SMS might be the most private data on my phone. They show where I eat, what I earn, who I send money to and when I'm broke.

With a closed model API, Salli would have to upload all of that to someone's server just to work out that "KEELLS SUPER" means groceries. I wouldn't use that app, so I wasn't going to build it.

Open weights flip that. Gemma runs on my laptop through Ollama and TabPFN runs there too. The phone talks only to the laptop, over WiFi I own. There's no account to make, no API key to leak, no usage bill and no company that can shut the feature off or change the price later. The AI is just part of the app, like the database.

Open source matters for the other half. Salli only knows Sri Lankan banks and billers today. Because the rules, the prompt and the benchmark are all in the repo, anyone can add their own bank's format and test it, without waiting for me.

The Lazy Payoff

I pointed Salli at my real inbox: about 1,400 SMS going back years. I had never once added up my spending and the first time I saw it all in one place was a little uncomfortable. The roast didn't help.

Before, figuring out where my money went meant scrolling through SMS and adding numbers in my head, which in practice meant never. Now it's one tap on the phone. The rest happens while I'm doing something else or nothing at all, which is the sloth way.

Prize Categories

Gemma: Gemma 3 4B runs locally through Ollama to read new bank SMS into structured transactions with a JSON schema and to write the monthly spending roast.
TabPFN: TabPFN regression forecasts daily spending for the rest of the month from past days, running locally as an optional sidecar.

ShopSnap: WhatsApp order screenshots to a daily sales report, with AI that stays on your PC

Sasmitha Ashinsana — Sat, 17 Oct 2026 19:28:10 +0000

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

What I Built

ShopSnap turns WhatsApp order screenshots into a daily sales report. It is made for small shops that take orders over chat.

Lots of small sellers run their whole business inside WhatsApp. A customer writes "2 kg rice and 1 dozen eggs" and the owner replies with a price. By evening the orders are spread over dozens of chats. Who ordered what? Who paid? Who still owes money? Most owners answer that by scrolling back through every chat or by trusting their memory.

Here is how ShopSnap handles it:

Drop in the screenshots and pick the business date.
A local vision model reads each chat. A local text model turns it into orders.
You review and fix every order. Nothing is saved until you click Confirm.
You see total sales and who has not paid and a total for each customer.
Mark orders as paid (full or part) and copy a ready follow-up message to paste into WhatsApp.

Chats that show only a saved name go to a Pending list. You attach a phone number once and ShopSnap remembers that name from then on.

Who would pay for it: any shop owner who sells over chat and keeps the books by hand. The app is free and MIT licensed today. The version I would sell is a packaged desktop app with the setup done for the shop owner. That part is future work.

Demo

Upload and review. Drop screenshots then check and fix every order before saving.

Pending. Chats that show only a name wait here until you attach a phone number.

Daily report. Total sales and who has not paid and a total for each customer.

All screenshots use fake demo data.

Code

sasmeee / shopsnap

Turn WhatsApp order screenshots into a daily sales report. Runs fully locally with Ollama. Customer data never leaves your PC.

ShopSnap

Turn WhatsApp order screenshots into a daily sales report. Built for small shops.
The AI runs on your own PC. Customer numbers and sales never leave it

Built for the Hacktoberfest Open-Source AI Challenge, Week 2: Side Hustle.
The repository was started on October 15, 2026, inside the challenge window.

Demo video: Watch on YouTube
DEV post: ShopSnap: WhatsApp order screenshots to a daily sales report, with AI that stays on your PC

Screenshots

Upload and review. Drop screenshots, then check and fix every order before saving.

Pending. Chats that show only a name wait here until you attach a phone number.

Daily report. Total sales, who has not paid, and per-customer totals.

All screenshots use fake demo data.

What it does

Drop WhatsApp screenshots and pick the business date.
A local vision model reads the chat. A local text model turns it into orders.
You review and…

View on GitHub

How I Built It

Stack: Next.js (App Router and TypeScript) with shadcn/ui and Tailwind. SQLite through better-sqlite3. Ollama runs the models. zod checks the JSON. libphonenumber-js handles phone numbers and sharp resizes the images.

Open models, both run locally through Ollama:

gemma3:4b reads the screenshot and writes out the chat as text.
qwen2.5:3b takes that text and extracts the orders as JSON.

The pipeline:

screenshot -> resize -> vision model (text) -> text model (JSON)
-> code checks -> you review -> SQLite -> report

Two small models on a normal PC will make mistakes. So I did not build the app around trusting them. I built it around checking them. The model proposes and plain code decides:

A phone number is the only customer ID. A chat name never creates a customer.
Code decides whether the chat header is a number or a name. The model does not.
Every amount the model returns must appear in the chat text. Items must add up to the total. A failed check blocks the Confirm button.
"Paid" is accepted only if the chat has payment words. Otherwise the status becomes unknown and the owner decides.
The same screenshot twice is never counted twice. I hash it and store the order position.
Only the hash is stored. The image is never kept.

I tested the pipeline on 10 fake screenshots with bun run eval:

Measure	Result
Screenshots	10 (fake chats)
Orders	11
Fields correct	90 of 107 (84.1%)
Screenshots with every field right	8 of 10
Orders with a wrong field	3 of 11
Wrong orders the code checks did not flag	2
Average time per screenshot	about 26 s on my PC

One screenshot did most of the damage. Chat 07 holds two orders. The model returned one and misread its amounts. That single chat caused 15 of the 17 wrong fields. The other miss was in chat 09 where the model misspelled a name and guessed "unpaid" when the status should have been "unknown".

Two wrong orders got past the code checks. One of them is the order the model never returned. Nothing can validate an order that is not there.

What I learned: a 4B model is weakest on chats with more than one order. The checks are good at catching wrong numbers but they cannot catch a missing order. A forced re-read can find an order the first read missed. The review screen is the last safety net before anything is saved.

Real chats are messier than my fake ones so expect lower numbers. That is why the review screen is not optional.

Why Does Open Innovation Matter?

A shop's chats hold customer phone numbers and daily sales. That is private data. With a closed API every screenshot would leave the shop's PC and travel to someone else's server. Many owners would never accept that and I would not blame them.

Open weights changed three things for ShopSnap:

Privacy: the models run on the owner's own machine. Numbers and sales never leave it.
Cost: there is no bill for each screenshot. A shop that processes 40 chats a day pays nothing extra.
Control: the models are two environment variables. If a better small model comes out, you change VISION_MODEL or TEXT_MODEL and you are done. It also works offline after the first download.

The honest trade is accuracy. Small local models are weaker than the biggest hosted ones. I answered that with code checks and a human review step instead of a bigger model.

Both models keep their own licenses. Gemma 3 is under the Gemma Terms of Use and Qwen2.5 3B is under the Qwen Research License. The README tells anyone to read both before using ShopSnap in a paid setting.

Prize Categories

Best Use of Gemma: Gemma 3 (gemma3:4b) is the vision model that reads every screenshot. Without it nothing else in the pipeline has any text to work on.

SafeCamp: an offline campsite safety check that runs on your phone

Sasmitha Ashinsana — Sun, 11 Oct 2026 10:40:54 +0000

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

You find the perfect spot. Flat ground, a stream nearby, no one around. You also have zero bars and there is a grey papery lump hanging from the branch above where you wanted to put your tent.

That moment is why I built SafeCamp.

What I Built

SafeCamp is a campsite safety inspector that works with no signal. Point your phone at a plant, an insect, a nest or a patch of ground. It tells you how worried to be and what to do next, in four levels: Favorable, Caution, Danger, Critical.

Example advice: “Move your tent pitch at least 30 m away.”

The whole check runs on the phone. You open the app once on Wi-Fi, the vision model is cached and from then on it works in airplane mode. The photo never leaves the device.

How it fits “Touch Grass”

Most apps compete for your attention. This one is built to give it back. It is only useful when you are standing outside, in the place you are about to sleep and it is meant to take seconds: scan, read the card, move the tent, put the phone away.

It is for anyone who camps, hikes or picnics somewhere unfamiliar. It removes one reason to stay home: “what if I run into something I cannot identify and cannot look up?”

Demo

Live app: safecamp.onrender.com

(Open it once on Wi-Fi, then try airplane mode.)

Four real scans from the app

RISK: DANGER Snake - 83%	RISK: DANGER Wasp or hornet nest - 95%
NO KNOWN HAZARD Looks like: Pet dog - 97%	NOT SURE, BE CAREFUL Possible: Risky campfire - 38%

Code

sasmeee / safe-camp

SafeCamp

An offline campsite safety inspector. Take a photo of a plant, insect or piece of ground,
and get a color-coded risk level and what to do about it, with no signal and no upload

Built for the Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.
The repository was started on October 8, 2026, inside the challenge window.

Live demo: safecamp.onrender.com
Demo video: Watch on YouTube
DEV post: SafeCamp: an offline campsite safety check that runs on your phone

Why this exists

Good camping spots tend to have bad phone signal. That is exactly where you meet an unfamiliar insect, a plant you do not want to touch, or a dry gully you should not sleep in. Searching the web is not an option there, and a photo of your campsite is not something everyone wants to upload anyway.

SafeCamp runs the whole check on the phone. The photo…

View on GitHub

MIT licensed. The README covers running it locally and adding your own hazards.

How I Built It

The model

SafeCamp uses CLIP (Xenova/clip-vit-base-patch32, int8 ONNX) through Transformers.js. It runs on WebAssembly inside a Web Worker so the UI never freezes.

There is no training. CLIP compares the photo with text prompts like:

“a photo of a paper wasp nest with hexagonal honeycomb cells”

The closest prompts win. Adding a hazard means writing a few sentences, not collecting a dataset.

The hazard list

41 entries live in one TypeScript file:

37 hazards (poisonous plants, stinging insects, snakes and large animals, unsafe terrain and water, fire and weather risks)
4 favorable signs (e.g. a flat, dry tent site)

Each entry has prompts, a short summary and action steps.

Making it fast

The first version re-encoded every text prompt on every scan.

With 5 hazards it was fine (~1.4 s). At 41 entries it grew to 3.6–5 s on my laptop.

The text side never changes, so I encode it once at dev time into text-embeddings.json. The phone only runs the image encoder. A scan is now back under 1.5 s. A script regenerates the file whenever prompts change.

Making it honest

This is where I spent the most time - a wrong “you’re fine” is worse than no answer.

Early on, a photo of an empty bird nest came back as “wasp nest, 97%”. The app had no bird nest class, so the nearest hazard won. I added 25 everyday labels (grass, bark, bird nests, rocks) so ordinary things stop being forced into a hazard.
A real hazard always outranks a favorable sign.
Related hazards pool their scores (a wasp-or-bee split still counts as “stinging insects”).
Low confidence gives a “possible, be careful” warning that names the runner-up - never reassurance.
“No known hazard matched” is never shown as “safe”.
Mushrooms, berries and snakes always say “treat as dangerous”, because a general vision model cannot reliably tell harmless ones from deadly ones.
Dark or blurry photos are flagged instead of judged.
A Why? panel shows the top scores. The score is a relative share between the app’s own labels, not a probability and the app says so.

Working offline

The app is a PWA cached by Serwist. One thing that bit me: by default the ONNX runtime loads its WebAssembly files from a CDN, which fails with no signal. I copy them into public/ort at build time and serve them myself.

On phones

Taking a photo on some phones reloaded the page and lost the result. I added an in-app camera and a gallery button on the result screen.

Stack

Next.js 16, React 19, Bun, Tailwind CSS 4, Serwist, Transformers.js, TypeScript.

AI assistance

I built SafeCamp with Claude as a pair programmer for design discussion and code review. I ran, tested and debugged everything myself. I deliberately avoided cloud APIs (hosted LLMs, databases, text-to-speech inside the app) because they would break the offline and privacy promises.

Limits

SafeCamp is a first-pass aid, not an authority. CLIP is a general model and will be wrong sometimes, especially on blurry, dark, distant or unusual photos. It has not been tested on a wide range of phones. Hazards differ by region and the advice is general. Follow local rangers, signs and emergency services.

Why Does Open Innovation Matter?

SafeCamp only makes sense because the model is open.

Privacy - An open-weight model can run on the device, so photos of someone’s campsite and kids are never uploaded.
No signal - A hosted vision API cannot work in the places this app is for. A model that is just a file on the phone can.
No cost per scan - No API key, no usage bill, nothing to rate-limit. A free tool for campers should stay free.
Changeable - The hazard list is plain text. Someone in Sri Lanka, Norway or Arizona can swap in their own hazards and thresholds without asking anyone.
Inspectable - Because the scoring is ours, I could build a Why? panel that shows exactly how a result came out. A black-box API would not let me do that.

Prize Categories

Best Use of Render - SafeCamp is deployed on Render as a free Web Service (bun install && bun run build, then bun run start) and it auto-deploys on push.
Best Use of GitHub - GitHub Actions runs lint and build on every push and pull request (.github/workflows/ci.yml).
Best Use of ElevenLabs - I used ElevenLabs to generate the narration for the demo video. The app itself does not call ElevenLabs, so the offline and privacy promises stay true.

Contact: dev.sasmitha@gmail.com