DEV Community: Mudit Palvadi

LynkShare: a no-login, cross-platform, fast file transfer platform

Mudit Palvadi — Sat, 24 Oct 2026 12:22:44 +0000

I built LynkShare because I hate logging into my email on a device I don't own. The usual file-sharing sites aren't much better: they either want an account, or they get awkward the moment you're sending more than one file.

LynkShare moves files between any two devices. No account, no email, and no one-file-at-a-time limit.

How it works

Open lynkshare.app in a browser, or the Android app, and pick up to 10 files.
It gives you a QR code and a six-digit code.
On the other device, scan the QR, open the link, or type the six digits.
The file goes directly between the two devices when the network allows it. When it doesn't, it goes through encrypted temporary storage instead.

The encryption key is created on your device and never sent to the server. It travels in the part of a link that browsers don't transmit, so the server only ever holds ciphertext. The six-digit code is a shortcut for not typing a link on the other device - the key is handed to that device directly, not stored for later lookup.

Start from either end

Most sharing tools assume the sender goes first. LynkShare works in both directions:

Sender first. Pick the files, then share a QR, a link, or the six-digit code. The receiver opens it whenever they're ready.
Receiver first. Open the receive screen on the device that wants the file and it shows a QR. Scan that from the sending device, and the files land on the device that asked for them.

Receiver-first is the one I use most: open lynkshare.app on a computer that isn't mine, hit "Pair with Phone", scan the code with my phone, done. No typing a link on a keyboard I don't own.

What's different

Tool	Where it stops
AirDrop	Apple devices only, and both have to be nearby.
Quick Share	Android, Windows and ChromeOS; needs the app on the computer.
WeTransfer	Works everywhere, but uploads your file to their servers, and larger sends need an account.
Snapdrop / PairDrop	Browser on both ends, but both devices must be open at the same time on the same network.
LocalSend	Excellent, but needs the app on both devices and the same network.
LynkShare	No account, no app on the receiving end, direct when possible, encrypted temporary storage when not.

The closest comparison is the browser-based P2P tools. The difference is the fallback: if the two devices can't reach each other, the transfer still completes instead of failing.

What it doesn't do

It's for quick handoffs, not file hosting. Ten files at a time; 10 MB per transfer on the web, 15 MB over the cloud path and 20 MB direct in the app. A rewarded ad raises those caps in the app.
Cloud copies are short-lived: 10 minutes by default, extendable in the app.
The Android app is in closed testing. iPhone users can use the website (can't afford that app store fee gng 🥀).
The interface and branding are temporary and I'll do a full revamp before the public release.
Sorry for the ads but they keep the free tier running.

What's next

Offline transfer: both devices on the same Wi-Fi, no internet at all, nothing leaving the network. It's the next feature I want to build, and it will be ad-free when it ships.

I need Android testers

I'm at the stage where Google Play wants 12 testers who stay opted in for 14 days before it will consider production access. So I'm asking for a small favour.

Cover as many of these as you can - the point is the platform combinations, not any particular pair of devices:

app to app with the six-digit code
app to browser and browser to app
browser to browser
at least one transfer in each direction
a direct transfer (both devices open) and a cloud one, so both paths get exercised

Where the app asks where to save downloads, pick a folder. Receive a file, force-stop the app, then receive another - that proves the folder grant survived.

Then tell me what you tested with, the OS version, and anything that broke. A screenshot of an error would be better than a paragraph.

Join the testing group - Install from Google Play

If you'd rather not test, thoughts on the approach are welcome too, THANKS!! 🙏

Links:

Website: lynkshare.app
Github: Website source code

STILL: the first esport for lying down

Mudit Palvadi — Sat, 24 Oct 2026 09:14:40 +0000

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

What I Built

I built the first esport for lying down.

There is no controller. No keyboard. No skill tree. You give the browser permission to use your webcam, lie down, and try to stay completely still for 60 seconds while a referee powered by Gemma watches your skeleton and quietly judges you.

That is the whole game. One rule: do not move.

It sounds easy until the referee notices that your left wrist has been twitching and decides to do something about it. First it throws a dry little insult. Then it picks the joint you are least able to control and aims a temptation straight at it. A fly. An itch. A notification. If you move that exact joint, you lose double points. It is the most personal attack I have ever received from a language model.

Your score comes from how still you were, how long your best freeze lasted, and how many times you betrayed yourself. The stillest human goes on the leaderboard. Everyone else gets a rank like Restless Meat Sack and a verdict that sounds like a disappointed butler.

Who gets to be a little lazier? Everyone. This is the only ranked activity where the best possible strategy is to do nothing, and the only setup is a laptop and a floor.

Demo

Play it here: still-s88j.onrender.com

Open it on a laptop with a webcam.
Allow the camera and lie down with your whole body in frame.
Hold still for 60 seconds while Gemma tries to ruin your day.

The free Render instance takes a short nap when nobody visits, so give it a minute to wake up. The video never leaves your browser. That is good for privacy and also good for everyone who does not need to see my ceiling.

Code

The code is here: github.com/mudit-palvadi/still. It is MIT licensed, because a game about doing nothing should be free to do nothing with.

The stack is React, TypeScript, TensorFlow.js MoveNet, Express, and Gemma 4 through Google AI Studio. Render serves the whole thing. The leaderboard uses MongoDB when a database is available and memory when it is not, which is a polite way of saying it forgets you after a restart.

How I Built It

The camera part uses MoveNet, a pose model that runs in the browser and finds 17 points on your body. Every joint is measured against your torso length, so leaning toward the camera does not count as movement. Calibration watches you fidget for three seconds and learns your personal baseline, because some of us are born at 90 percent vibration.

Gemma is the fun part. At a few cue points the browser sends a small packet of stats to the server: time, rating, betrayals, your weakest joints, and your last act of cowardice. Gemma has to reply with strict JSON, one line and sometimes one joint to target.

The server checks the joint and cleans the line before it reaches you. If Gemma is slow or unavailable, a bank of offline lines keeps the round moving. The game never breaks. It just becomes less creative about your posture.

My favorite bug of the week: the first live build used Gemma 3, which Google retired from the Gemini API. The referee did not crash. It quietly fell back to the offline lines, which is the AI equivalent of a waiter saying the kitchen is closed while still serving soup. I moved to Gemma 4, added a diagnostic to the health check, and confirmed the next live line actually came from the model. The first thing it did was threaten my wrist.

I also ran a full round with a fake camera feed and found two scoring bugs. At low frame rates, a perfectly still player scored about 12 instead of 100. And a freeze of 60.3 seconds was rejected by the server because the limit was 60. Both are fixed. The lesson: always test your fake skeleton before you trust a real one.

Two dev.to posts gave me the confidence that this was possible. Mathias Leonhardt built a bird flight simulator you control by flapping your arms. Muhammad Umer Farooq built an AI workout tracker that runs entirely in the browser. Both proved that pose tracking in a web page is not a toy. I borrowed the confidence, not the code. The difference here is the loop: the model is not counting reps, it is actively trying to make you fail.

Why Does Open Innovation Matter?

The pose model runs on your device. The video never leaves the laptop. That is a privacy win, but it is also a creative one: no upload, no queue, no bill that grows every time someone scratches their nose.

Gemma has open weights. I tested the referee loop locally with Ollama before I trusted a hosted key. If the model changes tomorrow, I can point the server at another provider or run it myself. A closed API would make the referee a rental. Open weights make it a cast member I can recast.

The whole project is small enough to read in an afternoon. Every interesting part is inspectable, from the scoring math to the prompt. That is the kind of open innovation I care about: not just free code, but a game you can take apart and make weirder.

The Lazy Payoff

The pitch is a joke with a real edge. Most apps compete for your effort and attention. STILL asks for neither. It saves 100 percent of the effort by design and turns doing nothing into a ranked skill.

The game will teach you that your nose moves more than you think. If you get CERTIFIED STATUE, screenshot it and tell everyone. Nobody will care, but you will know.

If you try it, bring a webcam and the ability to ignore an itch. One of those is harder than it sounds.

Prize Categories

Best Use of Gemma: Gemma 4 is the referee, the game director, and the reason a round has a personality. It chooses what to say, which joint to attack, and how to summarize your failure.

Best Use of Render: STILL runs on a Render web service created from a render.yaml blueprint, with a health check and a free instance that wakes up when someone wants to lie down.

LeadRadar: Finding clients shouldn't cost you an afternoon of scrolling Google Maps

Mudit Palvadi — Wed, 14 Oct 2026 18:02:17 +0000

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

Every freelancer I know has a secret ritual, and it is not making work. You pick a city, open Google Maps, and start scrolling. Does this pizza place have a website? Does that salon answer its reviews? You open twenty tabs, you copy names into a spreadsheet, and eventually you write an email that begins "I came across your business" when the truth is you scrolled past four hundred businesses to find it.

I have always hated that hour more than any actual client work. So for week 2 of Hacktoberfest I built the thing I wanted: LeadRadar, an AI agent that reads Google Maps for me, tells me which local businesses genuinely need my help, and drafts the outreach email while the coffee is still hot.

You give it your trade and your city, for example graphic designer in Austin, TX. It searches, scores every result, and hands back a ranked list with an email ready for the top lead. Change the trade to content writer or web developer and the flow stays identical, because the trade only changes what the agent looks for, not how it thinks. That claim sounds simple. It took a friend telling me it was false to make it true, and that story is in the second half of this post.

What I Built

LeadRadar has four moving parts:

A search layer that builds one Google Maps query out of your trade and runs it through SerpApi.
A scoring layer that ranks every business out of 100. Most of each score comes from facts inside the search result itself: does this place have a website, is its rating quietly hurting it.
An email layer that drafts a short personal note for your top leads and signs it with your name.
A Temporal workflow that runs search, scoring and drafting as separate steps with retries, so one rate limit does not kill a scan.

The stack is deliberately boring: Express for the API, MongoDB Atlas for storage, Groq's free tier for the model (allam-2-7b) with Ollama as the local fallback, and SerpApi for search. It deploys as a single Render service, is MIT licensed, and there are 68 tests keeping me honest.

Demo

Live site: https://leadradar-7ukg.onrender.com

It runs on Render's free plan, so the first visit after a quiet period takes about a minute while the instance wakes up.

The scan form asks four things: what you do, where you work, your name, and how many leads you want.

While the workflow runs, each step lights up as it finishes.

Then the list comes back ranked, with the signals next to each score so you can see why a business placed where it did:

And the top lead already has an email written:

It works on a phone too, which matters if you are checking leads between calls.

Code

The whole thing is at github.com/mudit-palvadi/lead-radar under the MIT license.

How I Built It

1. The query is written for your trade, not typed by you (SerpApi)

You never compose a search yourself. You type "graphic designer", and the agent asks a model which local businesses would hire one, then joins the answer into a single Maps query:

coffee shop OR bakery OR restaurant OR bar OR food truck OR real estate agent OR gym OR salon ... in Austin, TX

One SerpApi Google Maps call later, I have the leads: name, address, phone, website, rating, review count, category. Structured data I can reason about, instead of a page I have to scrape and hope the markup did not change.

Two things here were learned the hard way.

The prompt only knew one trade. When my graphic designer friend ran a scan, the agent proposed toy store, pet store, car wash, bookstore (and bookstore twice). Those are businesses, technically. None of them were sitting there waiting for a designer. The prompt had exactly one worked example in it, for web design, and the model never generalized past it. I ran the diagnostic script three times and watched it return the same wrong list, then rewrote the prompt to show examples across trades and to ask a sharper question: which businesses would an owner pay for out of their own pocket? I added deduplication, and taught the peer filter to catch near misses like design studio when the trade is graphic designer. The same script now returns coffee shops, bakeries, food trucks and an art gallery. I reran a real Austin search with it and got 15 businesses I could actually imagine emailing.

SerpApi occasionally returns a row that is not a business. Most often it is the city name handed back with no real title. A lead called "Austin" invites the model to invent details about it, so isUsableResult() drops rows like that before they reach the list. My last scan logged "dropped 1 unusable result", which is exactly one fewer embarrassing email.

2. Facts come from the search, opinions come from the model

The first version of the scorer trusted the model completely. It answered 70 for every single lead, whether the business had a website or not. A score that never changes is not a score, it is decoration.

So the division of labor is now strict. detectSignals() reads the raw SerpApi record and derives facts I can verify: no website is a strong buying signal for any trade, and a low rating with a pile of reviews is another. The model only returns a number and a sentence of reasoning, and the final score is a blend:

// src/workflow/activities.ts
let base = 30;
if (has('no_website')) base += 55;
if (has('bad_reviews_no_response')) base += 15;

const blended = base * 0.75 + clamp(modelScore, 0, 100) * 0.25;

75 percent of the score is arithmetic anyone can read. The model gets a quarter of the vote, enough to break ties, not enough to pretend it saw something it did not.

3. The emails survive contact with a 7B model

The prompt asks the model to sign off and to stop commenting on things it never looked at. The model does it anyway, cheerfully. So the checks live in code: ensureSignOff() looks at the tail of the draft and appends your name if the model forgets (it often does), cleanEmailBody() strips sentences where it confesses it never checked the website and removes the "I hope this email finds you well" it was told not to write, and pitchGuidance() keeps a graphic designer from offering to build a website, which is the kind of thing that makes an outreach email read like it was generated.

The rule I settled on: never fight the model over instructions in the prompt when I can check the output in code.

4. One workflow, one free service

The scan, classification and drafting steps run as Temporal activities. Batches of three classification calls keep me inside Groq's free tier token limit, and retries absorb the rate limits that come with it. Results land in MongoDB Atlas, so a completed scan is still there after a restart.

Render's free plan does not allow background workers, so scripts/start-all.js boots the API and the worker together in one web service. The prompt fix from section 1 went live by itself when I pushed, because everything is defined in one render.yaml blueprint.

What it does not do yet

Scores only matter next to each other inside one scan. An 81 in Austin is not a promise about your city.
The emails are drafts. Read them before you send them. Mine survived that test with my friend's leads, but your name is the one on them.

Why Does Open Innovation Matter?

Because the tools that find clients are usually the ones sold back to the people who need them. For years my options for lead discovery were either a monthly database I could not afford or a scraper someone dressed up as a service. Meanwhile the libraries I actually build with are free and readable.

I am not the first to treat Google Maps as a lead source: How I Built a Google Maps Scraper to Generate Leads for My New Agency (And Why I Open-Sourced It) by @j3rry320 and Build a Local Lead Gen Machine: Scraping Google Maps with n8n (Reliably) by @wanjiang go after the same data, and most advice for freelancers is still a list of things to do by hand, like How to Get Freelance Design Clients Without Upwork: 15 Strategies That Actually Make Sense by @ahmed_quadri_4dd8a159217f.

What open changes is the reasoning. Anyone can read why a bakery outranked a boutique, argue with the weights, and send a pull request. The black box lead list you can only buy and the readable one are not the same kind of product. I know which one I would rather hand a freelancer who is just starting out, because that was me not long ago.

My First User

Before publishing this, I gave LeadRadar to two friends who freelance for real.

The web developer ran a scan for his city and was struck by how fast it was. He picked one of the leads, sent the outreach email the agent had drafted, and came back to tell me it had not converted. One email rarely does. What he actually said was that he liked the app and would surely use it again, and now he has a shortlist he did not have before, made in about a minute.

The graphic designer got the opposite result. The app could not find good leads for his trade, and he told me it looked like the app was more optimized for other skills. He was right, and he did not say it politely, which was the more useful part. That complaint is what sent me to the diagnostic script and the prompt rewrite in section 1. After the fix, his kind of scan returns coffee shops, bakeries and event venues instead of toy stores.

Would they pay? Neither has paid me anything, and I did not ask. The developer promising to come back and use it again is the only vote I have so far, and it beats any demo I could record myself.

Two lessons I am keeping:

Speed impressed the developer more than any feature did. He was comparing LeadRadar against his own afternoon of scrolling.
A "works for every freelance skill" claim is only honest once it works for every skill a real person has tested. Two trades are tested now. The claim is still smaller than my ambition, and I would rather say that out loud than hide it in a footnote.

Prize Categories

One project, every category it genuinely uses:

Best Use of SerpApi: the whole discovery layer, not a side feature. Every lead, signal and score starts from one Google Maps query.
Best Use of Render: one free service runs both the API and the worker, defined in render.yaml, rebuilt on every push.
Best Use of Temporal: scan, classify and draft run as retried activities, with their progress shown on screen.
Best Use of MongoDB Atlas: scans, leads and drafted emails are stored in Atlas and survive restarts.

Over to you

Try a scan for your own trade at leadradar-7ukg.onrender.com. If the leads come back as wrong for your trade as my friend's did for his, open an issue and tell me. That is exactly how this gets better.

I Touched Grass And All I Got Was This Absurd Receipt

Mudit Palvadi — Sat, 10 Oct 2026 09:39:58 +0000

I Touched Grass And All I Got Was This Absurd Receipt

Built for the Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

One button. Tap it on the way out, tap it on the way back. While the phone is in your pocket it counts your steps and notices when you stop moving. When you come back, a language model running entirely on the device prints a thermal receipt of your time outdoors.

The screen is the shortest part of the experience — you look at the phone for ten seconds going out and ten seconds coming back.

What is actually here

                GRASS TOUCHED
              RECEIPT NO. 1
------------------------------------------------
WENT OUTSIDE                      12:32 AM
COME BACK                         12:33 AM
TIME BAND                      AFTER DARK
WALK TYPE                          STEP OUT
------------------------------------------------
0x   STEPS, ON YOUR GOOD LEG
1x   MINUTES AWAY FROM THE SCREEN
1x   THE FRONT DOOR
1x   COLD AIR, BRIEFLY
1x   A CHANGE OF MIND
------------------------------------------------
TOTAL                        $0.00

WHAT THE GRID MISSED
LESS THAN A MINUTE OFF THE GRID.

YOUR REVIEW
2 stars. Did not get far.

SIGNOFF
Come back tomorrow. Grass misses you.

That last receipt is from a real 20-second walk. It is not a screenshot from a design tool. It is what the app actually printed.

The most interesting thing that happened: Qwen3 would not stop thinking

The first model I tried was Qwen3 0.6B. The first receipt on a real device came back as a template receipt — the app's honest fallback — and the log named the reason:

ReceiptService: rejected (tooFewLines) on both attempts.
raw: <|channel>thought | Okay<channel|><|channel>thought | ,<channel|> ...

Every token of its 512-token output budget went into thought blocks. The receipt itself never appeared.

I tried the obvious fix first. flutter_gemma's InferenceChat appends /no_think to the prompt for Qwen3 when isThinking: false — so I switched from the raw createSession() to createChat(), which is the only layer that knows about thinking models. That was necessary and not sufficient.

Grepping flutter_gemma_litertlm for enableThinking, no_think or extraContext returns nothing. The .litertlm engine never wires thinking off at all. On a real phone Qwen3 still thinks until it runs out of budget.

So the default is now SmolLM2 360M — ungated, not a thinking model, and fast enough to answer between two taps. Qwen3 stays selectable with a note saying what it does, because a receipt that names its model should be honest about which ones do not work.

This is also why the fallback exists and why the UI says "Template receipt printed: … Your steps and minutes are still the real ones" instead of hiding it. A silent failure here would have looked like a working app with bad jokes.

What the AI model is actually for

The honest answer, because it is the question a submission should be able to survive: the sensors measure, and the model judges.

The phone measures steps, minutes, time band and the longest standstill. It cannot decide what kind of walk those add up to, how many times something plausibly happened, or what the offline minutes meant for the natural world. Those are the model's job.

Four things come from the model and not from the phone:

A verdict on the walk — WALKTYPE, one of a closed set: STEP OUT, ERRAND, A SIT, LOOP, A PROPER WALK, WANDER, ESCAPE, COMMUTE. It is the line a reader can disagree with, which is the point.
Item quantities. The model writes 44x BIRD THAT SAW YOU, so a three-hour walk and a bathroom break do not produce receipts that look interchangeable.
The nature line, which must quote the measured minutes.
The comedy — item names, review, signoff.

Why the quantities are bounded, not trusted

The model chooses them, so its output cannot be fully verified: nobody knows how many birds there were. What can be checked is whether a number is possible, and that is the one rule enforced in parseOutput:

// Nothing happened more times than there were minutes to happen in.
final maxQty = 1 + facts.minutes;

A ten-minute walk cannot claim twenty birds. A claim of 999 steps on a 43-minute walk is thrown out entirely.

ReceiptLine.measured records which lines are the phone's. The measured step and duration lines are built in Dart and prepended, so a model that writes its own 12x STEPS line prints next to the pedometer's real count without ever replacing it.

The nature line has its own check: it must contain the measured minutes as a whole number. A line that says "43 MINUTES" about a six-minute walk is decoration pretending to be fact. And a walk under a minute has no number to quote, so both the prompt and the check fall back to the phrase "LESS THAN A MINUTE" instead.

Why open

Every number above is true in the boring, checkable sense:

No server. There is no backend, no database, no account, no analytics.
No signal needed. The receipt is written on the device. It works on a trail with no bars.
Nothing leaves the phone. Location is never requested. Steps and timestamps live in a value object and are discarded when the process ends.
Nothing to pay. No API keys, no token metering, no inference bill.
Swappable. The prompt is model-agnostic and the model is a constant in gemma_runtime.dart. Three are wired up and selectable in the app, so "open" is a switch you can flip rather than a claim in a README.

That last one is the point worth making in the write-up. A closed-API version of this app would be a fetch and an API key. The open version is a 356 MB file, a prompt you own, and three models you can replace without asking anyone.

The printing

The receipt does not appear already printed. It feeds out of the slot in 14 discrete steps over 1.7 seconds, with a dark band tracking its leading edge while it is still inside the machine.

The steps are the part that matters. A single eased glide reads as a web page loading; the jumps read as a roller tick-tick-ticking. Each step reveals another ~1/14th of the paper, so the header prints first and the torn edge appears last.

The torn edge itself is a CustomClipper with 40 teeth at 4px depth, and the dashed rules are a CustomPainter that clamps its last dash instead of letting it overshoot. Both are unit tested without rendering anything, because a clipper that closes at the wrong place still renders as a grey shape and looks like paper.

What I would do differently

The walk ends if the process dies. Sensor streams are held in the app; there is no background service. Closing the app mid-walk loses the walk. A workmanager periodic sample would fix it and is the obvious next step.
Standing still is measured from gaps between step events, not a motion classifier. Ten seconds without a step counts as a stop, so a red light does not register but a bench does.
I would not have hardcoded an example number in the prompt. A 20-second walk printed a template receipt because the model copied "43 MINUTES" out of the example and then failed the check it was meant to demonstrate. The example now carries the walk's own numbers.
The receipt could be taller. A six-line receipt with the machine above it fills a phone screen, so the paper is sized to its content rather than allowed to scroll.

Code

mudit-palvadi / grass-receipts

Grass Receipts

lines; the idea is older than both projects Flutter, and the inventor is credited rather than ignored. The maths is three

Grass Receipts

I touched grass and all I got was this absurd receipt.

                GRASS TOUCHED
              RECEIPT NO. 42
------------------------------------------------
WENT OUTSIDE                        4:04 PM
CAME BACK                           4:47 PM
TIME BAND                    LATE AFTERNOON
------------------------------------------------
1234x STEPS, ON YOUR GOOD LEG
43x   MINUTES AWAY FROM THE SCREEN
1x    BENCH OCCUPIED, BRIEFLY
3x    BIRD THAT SAW YOU
1x    BREEZE, MILD, SUSPICIOUS
------------------------------------------------
TOTAL                        $0.00

YOUR REVIEW
3 stars. Great breeze, no wifi.

SIGNOFF
Come back tomorrow. Grass misses you.

The…

View on GitHub

Running it

flutter pub get
flutter run            # downloads SmolLM2 on first launch, automatically
flutter test           # 45 tests, no device or model needed

First launch downloads 356 MB because the receipt writer has to live on the phone. Choosing Gemma adds a token field on the setup screen; it is held in memory for the length of one download and never written to disk.

The repo is at github.com/your-handle/grass-receipts. MIT licensed. The Gemma weights are downloaded at runtime under Google's Gemma Terms of Use.

Built for Hacktoberfest Open-Source AI Challenge: Week 1. Tag: #hf26challenge.

I built an app that reads my dyslexic friend's email for him

Mudit Palvadi — Mon, 05 Oct 2026 06:57:35 +0000

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

What I Built

Heads Up — an Android home-screen widget that shows at most three emails that actually matter, as three short plain lines, each with a play button so it can be listened to instead of read.

I built it for a friend of mine.

He is dyslexic. He is smart and entirely capable of running his own inbox, he just doesn't, because the inbox is a wall of text and the wall costs him more than the contents are worth. So important things sit there. A college form with a deadline. A question from a friend he wanted to answer. Things that would have taken four minutes, if he'd seen them on the day they arrived.

The insight

The usual advice for "I can't keep up with email" is filters, rules, priority inboxes, muting senders. All of it still leaves him doing the reading.

His problem isn't that the inbox is too noisy. It's that the inbox is somewhere he has to go. Nobody walks past their own front door. You have to make a decision, and deciding is the expensive part.

So: don't make him check it. Bring it to him. Three things on the screen he already looks at forty times a day, written in the fewest words that still mean something, and a button instead of a paragraph.

Three items maximum, ever. And when there's nothing, it says Nothing needs you today ✓ rather than showing an empty box — an empty widget gets deleted, and a deleted widget gets missed.

Demo

Code

mudit-palvadi / heads-up

Heads Up

MIT licensed — see LICENSE. That covers this source code only; the Gemma weights are downloaded at runtime under Google's Gemma Terms of Use.

The three things that need you today, on your home screen.

Built for a friend who is dyslexic, rarely opens his email, and misses the things that matter. Heads Up puts at most three flagged emails on his Android home screen as short plain lines, each with a ▶ button so he can listen instead of read.

The widget is the product. The app is only setup and a control panel.

Status — what is actually verified

This is the honest picture, because "it works" is not a useful claim.

Area	State	Evidence
Rules engine + cleaner	Verified	20 hand-written fixtures; every pass/fail row in `rules.md` §8 asserted. Pure logic, no device needed.
On-device inference	Verified on hardware	Gemma 3 1B-IT via LiteRT-LM

…

View on GitHub

MIT licensed. 32 commits, 277 tests, flutter analyze clean under
strict-casts / strict-inference / strict-raw-types.

flowchart TD
    A["Gmail (IMAP)<br/>EXAMINE + BODY.PEEK"] --> B["Cleaner<br/>HTML to text, strip quotes and signatures"]
    B --> C["RulesEngine<br/>VIP, keywords, deadlines, bulk"]
    C -->|not important| X["dropped"]
    C -->|important| D["Gemma 3 1B-IT<br/>on-device via LiteRT-LM"]
    D --> E["Validator<br/>shape and deadline match"]
    E -->|rejected| F["Template fallback"]
    E -->|accepted| G["ElevenLabs<br/>summary to mp3"]
    F --> H["WidgetSync"]
    G --> H
    H --> I["Home screen widget<br/>max 3 rows"]

How I Built It

Gemma 3 1B-IT — open-weight, running fully on-device via flutter_gemma / LiteRT-LM.
OpenCode — the open-source agent harness I built the whole thing with.
ElevenLabs — voice synthesis for the summaries.
Flutter, enough_mail for IMAP, home_widget, just_audio.

Two decisions that mattered more than the model

Importance is never inferred by the AI. A 1B model asked "is this
important?" will confidently declare a shopping newsletter urgent. So the rules
engine decides — with auditable regex you can read and argue with — and the
model's only job is rewriting text already judged worth showing. If the rules
engine can explain why an email is on the widget, that explanation survives.

The model is never allowed to invent a date. The rules engine extracts
deadlines by regex and hands the value to the prompt. If the model's BY:
doesn't match, the entire output is rejected and a template is used instead.
For someone who might act on a wrong date, a dull correct line beats a fluent
wrong one every time.

Gemma running on his phone isn't a nice-to-have. It's the whole
architecture.

His inbox has personal things in it — medical, family, college. A cloud LLM
would mean every one of those emails crosses a network to be read, and I'd have
to tell him so. Running a 557 MB open-weight model locally means the most
sensitive step never leaves the device. It also means $0 per email, so
there's no meter quietly encouraging him to read fewer of his own messages.

The interesting part is what a small model forces you to build. A frontier
model could probably judge importance on its own. A 1B model can't — so the
architecture gets organised around what the model can't do: decide what
matters, and invent a date. Those two jobs are pushed into a deterministic,
readable, unit-tested layer, and the model is left doing the one thing it's
good at, rewriting text into plainer text.

That's a better shape regardless of model size: the parts that must be right are
verifiable, and the part that's good at pattern-matching prose is allowed to be
fuzzy because a validator stands behind it.

Where I wasn't open, said plainly: ElevenLabs is a proprietary cloud API.
It's the voice — the part he actually experiences — and a synthetic voice that
sounds like a robot would undercut the whole point. It's switchable off, and
when it's off his phone's own TTS reads the line. The network call carries a
~30-word summary, never an email, but it is still the one place content leaves
the device.

Prize Categories

Best Use of Gemma — Gemma 3 1B-IT runs fully on-device via LiteRT-LM and rewrites every flagged email, with each output validated against a rules-engine-extracted deadline before it's allowed to reach the screen.
Best Use of ElevenLabs — summaries are voiced with ElevenLabs and cached as mp3s on the device so play is instant and works offline.

Built with

Gemma 3 1B-IT ·
ElevenLabs · OpenCode ·
Flutter · enough_mail ·
home_widget ·
just_audio ·
flutter_tts ·
flutter_secure_storage