DEV Community: Rupam Das

I was too lazy to build an app for every chore. So I built JackApp.

Rupam Das — Mon, 26 Oct 2026 06:50:00 +0000

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

What I Built

I typed “remind me to drink water” and got a reminder with a Done button. It nudges me three times a day; tapping Done adds to a check-in count.

I also asked for an expense tracker: an amount, a note and a running total. Those are small chores. I wanted the effort of making a tool to match their size.

So I built JackApp: an Android app that turns a plain-language description into a small tool you can preview, save and use again.

Jack of all trades, master of your chores.

Gemma 4 E2B runs on the phone through LiteRT-LM. After a one-time download, you can build supported tools offline. JackApp uses seven pre-built recipe families: lists and logs, counters, calculators, timers, reminders, bill splitters and AI helpers for text or photos.

I didn't have to build a screen, wire a button or set up storage for my reminder or expense log. Each tool keeps its own data, ready for the next time I need it.

Two examples of small personal tools. This illustration uses browser captures and example data.

Demo

The video walks through describing, previewing and using a tool. It uses phone-sized browser captures and example data; the Android generation measurements are in the evaluation section below.

To try on-device generation, you'll need an Android development build and the roughly 2.6 GB model download. The repository has setup instructions. There isn't a ready-to-install Android download linked here yet.

Code

ru-das / jackapp

JackApp

Jack of all trades, master of your chores. Describe a tiny tool in plain language and get a working mini-app, run on your own device with an open model (Gemma 4).

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 3. Web app: https://ru-das.github.io/jackapp/. Android: build it yourself (below).

The AI never writes code. It picks and fills in pre-built pieces, and the result is a JSON spec that the app validates and renders. Mini-apps and their data stay on the device. No accounts, no telemetry.

What it does

Create: type what you need ("track which plants I watered and remind me every Sunday"). You get a preview, then save it. A request the catalog cannot build gets a plain "can't build that yet" card instead of a broken app.
Ready-made starters: a checklist and a tip calculator on Home, no AI needed.
Mini-apps can use the model…

View on GitHub

Expo, React Native and TypeScript provide the app. Zod and semantic checks validate the generated descriptions. They are data, never executable code.

How I Built It

Three minutes, no usable tool

My first approach asked Gemma to describe the entire mini-app: layout, fields, stored values, actions and every connection between them. JackApp checked the result, asked for repairs, then checked again.

On my Moto G45, one attempt spent 175 seconds producing a description that failed validation. The repair then incorrectly refused the request. More than three minutes had passed, and I still had no usable tool.

Three minutes is a long time to wait for help remembering when you watered a plant.

I shortened the output, moved from full JSON to compact text, and asked repairs to return only the parts that needed changing. A follow-up phone test produced structurally valid fridge and plant tools, but the bill splitter and expense log still failed. Repairs made the results worse.

The model was repeatedly being asked to rediscover things I already knew: a counter's Add button increases a number; a log remembers its entries. I could put those connections in code once.

Gemma fills in. Recipes build.

I introduced recipes: pre-built app patterns with settings the model fills in.

For an expense log, Gemma supplies the fields and the total you want. The recipe supplies the form, Add button, saved rows and their connections.

The request “Log expenses with a name and amount and show the total spent” produced these settings, excerpted from the recorded phone run:

name Expense Log
description Log what you spend and see the total
noun expense
field name text Expense
field amount money Amount
total sum amount Total spent

Gemma asks for a name, an amount and a sum. Code builds the tool and calculates the total as entries change.

The recipe path is:

Request
  → check known capability limits
  → choose a recipe (ask Gemma to classify when needed)
  → Gemma fills in settings
  → code builds the description
  → validate → preview → save

If no recipe fits, or its settings are unusable, JackApp can try free-form generation with the same local model. That path is slower and less reliable. Descriptions that fail validation don't reach the preview or get saved.

Illustrated counter, timer and plant tools. Gemma supplies settings; recipes supply their structure.

What the generated expense log actually does

In a follow-up desktop replay, I took the expense description from the phone log and executed it through the current action engine:

Action	Result
Add Lunch 12.50 and Bus 7.50	Total: 20.00
Change Bus to 8.50	Total: 21.00
Delete Bus	Total: 12.50

Adding an entry also cleared the input fields. In the saved bill-splitter description, entering a bill of 120, a tip of 12 and four people produced 33 each.

These checks exercised actions and calculations with supplied values. They didn't exercise phone screens, persistent storage, notifications or receipt recognition.

Separately, manual phone checks covered offline building, saved data surviving reopening, grocery and receipt photo reading, and a reminder notification. Those were individual checks, not an accuracy study.

A saved tool can use Gemma again

Ordinary entries and calculations use app logic. A photo-enabled tool calls Gemma when you ask it to read a new image.

For receipt reading, I made a separate request that mentioned receipts; that feature wasn't part of the basic expense-log request above. JackApp cannot yet edit an existing tool through conversation.

The fridge tool has a similar division of work: Gemma lists visible food, you correct that list, and code compares it with the usual items you keep. You check the resulting shopping list before buying; a photo can't establish that something hidden at the back is missing.

Illustrative workflow with a generated sample photo and example results, not an OCR or vision-accuracy test.

What happened on the phone

On a Moto G45, Android 15, 8 GB RAM, the recipe run produced:

Request	Recorded result	Build time
Fridge-photo shopping list	Structurally valid	15.6 s
Plant watering tracker	Structurally valid; missed the requested tap behavior	18.5 s
Receipt-based bill splitter	Structurally valid	5.7 s
Expense log	Structurally valid	12.1 s
Interactive physics simulation	Rejected by the capability gate in code	—
Automatically fetched live weather	Rejected by the capability gate in code	—

The four descriptions passed without repair, with a 13.9-second median build time while the model was loaded, using GPU inference and speculative decoding. An earlier run measured 21.8 seconds to load the model.

The six-request log contains the prompts, settings and generated descriptions.

These times exclude model download, loading and later photo reads. Four structurally valid descriptions don't establish four correctly completed chores, and this wasn't a controlled speed comparison with the early 175-second failure.

The plant tracker shows why. I asked to tap a plant to record watering. Its generated tap action opened a name editor instead, leaving the watering date unchanged in the desktop replay. A List and an update action somewhere in the description satisfied the evaluator's presence checks. The preview still needs to be checked against the actual request.

Why Does Open Innovation Matter?

A receipt reveals spending. A reminder reveals a routine. A fridge photo was taken inside someone's home.

Open weights let Gemma run on the phone. In on-device mode, supported builds and photo reads don't send those inputs to a hosted inference service. There is no cloud fallback or per-request inference bill.

The tradeoff is the 2.6 GB download, plus memory, battery and waiting time. Local inference made long outputs expensive in a way I could feel: I was sitting there waiting. Recipes gave Gemma less to write, while keeping ordinary buttons, calculations and stored data independent of another generation request.

The source is open too. Someone can inspect how a description becomes a tool, change a recipe or add one. Its future doesn't have to depend on my finding time to maintain it.

The Lazy Payoff

I'm using JackApp for the little things I built it for.

My water reminder nudges me three times a day. I tap Done, and it adds to my check-in count. For expenses, I open my saved log, enter an amount and a note, and the total updates. With the receipt-enabled version, I photograph the receipt, check what it read, and save the expense.

I don't have to describe those tools again every time I need them. The reminder keeps its count, the log keeps its entries, and both are there when I come back.

That's the laziness I wanted: describe a chore once, make a tool for it, and keep using it.

Limits and Next Steps

There are practical limits. You provide the inputs: JackApp can't watch your bank account, read other apps or fetch live weather. Photo results need review. Reminders need notification permission, and the timer isn't yet a dependable background alarm.

Customize changes recipe settings such as labels, counter steps and reminder times; some still use structured text. Changes that could hide data offer to keep the old version as a copy. CSV export exists; mini-app export/import and conversational editing are unfinished.

Next I want to give someone JackApp without choosing their wording, see what needs correction, and find out which tools they return to. I'd compare the effort—including setup and corrections—with their existing method and a ready-made template.

Asking Gemma to describe an entire app left me waiting for something I couldn't use. Giving it a smaller job produced tools I could save and inspect. Now I want to find out which ones are still worth opening after the novelty wears off.

Prize Categories

Best Use of Gemma. Gemma 4 E2B supplies recipe settings and photo-assisted interpretation through LiteRT-LM, and can classify requests when keyword routing is uncertain. Code supplies the working structure and calculations. On-device inference works offline after the one-time download.

Built with Codex and Claude Code. I directed the project and tested it on my phone.

AI-Assisted Photo Culling with an Open Model, Fully Offline? Not a Myth Anymore.

Rupam Das — Mon, 19 Oct 2026 06:55:00 +0000

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

Meet Meera. She's an imaginary photographer (but 100% inspired by real photographers). Let's take a peek into her imaginary life (which is also 100% inspired by real photographers).

It's Saturday, close to midnight, and the wedding couple have just left in a car full of flowers. Meera drives home with about 2,500 photos on her memory cards. She has promised the couple a sneak peek by Tuesday, and before she can edit a single frame she has to look at every one of them and decide which one gets to grand finale of the photo album.

Photographers call that culling, and it's the slow part. During the ring exchange Meera held the shutter down, so now there are nine shots that look almost the same. Only one of them has nobody blinking. The ceremony runs into the portraits with no clear break. Somewhere in those 2,500 files is the one photo of the bride's grandmother laughing, and Meera knows the bride will ask for it.

AI culling tools exist, but Meera wants a workflow with no account, no recurring AI bill and no photo uploads. If a tool sends images to a server, someone else's computer sees the wedding.

A tool that does the boring part fast, with no account, no upload, and an AI the photographer actually owns, sounded like a myth. So I built MythiCull.

MythiCull runs on the photographer's own computer. It uses an open model, EmbeddingGemma 2, which is downloaded once. After that, it works with the wifi switched off.

What I Built

Meera opens MythiCull and selects the folder containing Saturday's photos. MythiCull imports the photos and creates time-based chapters. Meera can browse and rate immediately. The app offers a one-time model download, which she can defer. When she clicks Analyze photos, it creates image embeddings and caches them, skipping completed batches when analysis resumes after an interruption.

The workflow brings together four things:

It splits the day into chapters. A gap longer than 15 minutes starts a new chapter by default; chapters with fewer than three photos merge into a neighbour. These are time-based sections, rather than automatic detection of each wedding activity. After analysis, MythiCull also suggests a name for each chapter, like "Ceremony" or "First dance". Meera can take the name with one click or type her own, like "Grandpa's toast".
It groups bursts. Consecutive photos no more than 10 seconds apart that have similar embeddings join the same group within a chapter. Because consecutive matches can chain together, a group can span more than 10 seconds. In Suggested view, Meera sees one photo per group with a small badge showing how many are hiding behind it. Those nine ring shots become a single choice, and she can click the badge if she wants to check the other eight.
It suggests a frame. Without a description, the suggestion is the sharpest photo in the group. This is not a blink or facial-expression detector. If Meera cares more about feeling than focus, she can enter candid laughter under What to look for and adjust Suggested photo priority between Sharper photo and Closer match. The pick then moves towards the photo that matches her words best.
It lets her search in plain English. She types grandmother laughing, and the closest matches come first. No tags, and no one had to label anything.

Then Meera culls with the keyboard, which is how most photographers already work. P keeps a photo, X rejects it, 0 to 5 sets stars, the arrow keys move, and Ctrl/Cmd+Z undoes a mistake. Visible preview controls offer the same decisions and stars. Z switches to cached-preview pixels for inspection, and Pin reference holds another frame beside the current photo for comparison. The preview is capped at 1600 pixels on its long edge; this is not original-resolution RAW inspection.

When she's done, she has two ways out. MythiCull can write XMP sidecars next to her RAW files, for a later editing workflow. Keeps get a Green label and at least one star; rejects get Red and zero stars. XMP export covers RAW files other than DNG, excludes JPEGs and stars-only decisions, and has not yet been validated in Lightroom Classic or darktable. Or it can copy the keepers into a new folder, with one subfolder per chapter if she wants. Copies retain their original metadata; stars are recorded in a separate manifest. Both exports cover the whole project, regardless of the current chapter, search or filter.

It never touches the originals

Wedding photos can't be reshot. So MythiCull treats them carefully:

It never moves, renames, edits or deletes a photo. The only file it writes in the photo folder is an .xmp sidecar.
If a sidecar is already there and MythiCull didn't make it, MythiCull skips that photo and says so in the summary.
When copying, it never overwrites anything. If a file name is taken, the copy gets the next available numeric suffix, starting at _1.
Meera's choices are safe too. Importing again or indexing again never changes a keep, a reject, a star, or a chapter name she typed.

How Is It Different?

The big tools are good, and they're more polished than MythiCull is today. The real difference is who owns the AI. With MythiCull, the model is a folder on the photographer's disk, the code is open, and there's no account that can be locked or cancelled.

Feature	Photo Mechanic	Aftershoot	Narrative Select	MythiCull
AI suggests the best photos	✗	✓	✓	✓
Groups near-identical bursts	✗	✓	✓	✓
Splits a shoot into time-based chapters	✗	✗	✗	✓
Search photos in plain English	✗	✗	✗	✓
Choose picks using a typed mood	✗	✗	✗	✓
Keyboard-driven culling	✓	✓	✓	✓
Writes XMP sidecars for RAW photos	✓	✓	✓	✓
Exports keepers into chapter-based folders	✗	✗	✗	✓
Processes photographs locally, offline	✓	✓	✓	✓
Runs without a user account	✗	✗	✗	✓
Open-source application	✗	✗	✗	✓
Uses locally inspectable open AI weights	✗	✗	✗	✓

NOTE: This comparison is based on publicly documented features as of October 2026, not hands-on testing of every tool. ✓ indicates a documented feature; ✗ means the feature wasn't found in the documentation reviewed. MythiCull is still experimental, and some features await real-world validation.

Who Would Pay for It?

Photographers like Meera. Solo wedding and event photographers shoot thousands of photos per wedding, often work alone, and do most of their culling late at night. Every hour spent culling is an hour they don't spend editing, replying to couples, or sleeping.

They already pay for this problem, either with their evenings or with a monthly subscription.

MythiCull runs entirely on the photographer's computer. No servers to maintain, no per-photo API bills. That means it doesn't need a subscription.

MythiCull is free and open-source today. But imagine a polished, ready-to-install version that a photographer could buy for $49, just once, and keep for good. No monthly subscriptions, no per-photo fees.

Why $49? It's a price I think could make sense for solo photographers. Low enough to be approachable, while giving me a way to support continued development. And if it saves even a few hours of culling, that one-time cost could easily be worth it.

Demo

To run it yourself (Python 3.11+):

git clone https://github.com/ru-das/mythicull && cd mythicull
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
uvicorn mythicull.main:app --port 8000

Open http://localhost:8000. Accept Download model on startup, or choose Not now and return to it when you click Analyze photos. Create a project with Choose folder…, import the shoot, then analyze it. After the one-time download, the app works offline. A GPU makes indexing much faster, and you can start culling before indexing finishes.

Code

ru-das / mythicull

MythiCull

Local-first photo culling for wedding and event photographers. Import a shoot, let it index the photos, then cull with the keyboard. Picks export as XMP sidecars or copied files.

What it does

Imports a folder recursively. JPEG, and RAW through the embedded preview. RAW+JPEG pairs are treated as one photo.
Splits the shoot into story chapters by time gap (default 15 minutes). Chapters with fewer than three photos merge into a neighbour. Chapters can be renamed; renames survive re-runs. After analysis, you can accept suggested chapter names.
Groups near-duplicate bursts (within 10 s and similar image embedding) and suggests the sharpest frame in each group. The optional “What to look for” description (for example “candid laughter”) and “Suggested photo priority” slider balance sharpness with how well each frame matches the description.
Per-camera time adjustments for shoots with multiple camera models, without changing the original files or EXIF timestamps.
Plain-English…

View on GitHub

It's MIT licensed and was built during the challenge. The current suite passes 82 tests, with one real-model test deselected by default. The default tests run in seconds because they use a small fake model instead of the real one.

How I Built It

Here's the path a photo takes through MythiCull:

the photo folder (never changed)
  → find JPEGs and RAWs (a RAW+JPEG pair counts as one photo)
  → read the time each photo was taken
  → make small previews
  → split on gaps longer than 15 minutes; merge chapters under 3 photos
  → EmbeddingGemma 2 turns each photo into a list of 768 numbers
  → photos ≤ 10 s apart with very similar numbers → one burst group
  → the photographer culls → choices saved in SQLite → XMP sidecars or copied files

The back end is Python, FastAPI and SQLite. The front end is plain HTML, CSS and JavaScript with no build step. Even the fonts ship with the app, so the page never reaches out to the internet.

One model, four jobs

EmbeddingGemma 2 turns photos and words into numbers that live in the same space. That means a photo of a first dance ends up close to the words "first dance". This one idea does all the work:

Job	What gets compared
Burst groups	each photo with the one taken just before it
Search	the typed words with every photo
Mood pick	the typed mood with each photo inside one burst
Chapter names	the whole chapter with 18 wedding and event labels, like "Ceremony" and "Cake cutting"

Search is one line of math. A few thousand photos don't need a special database:

q = embedder.encode_text([query])[0]
scores = matrix[keep] @ q  # vectors are unit length, so this is cosine similarity
order = np.argsort(-scores, kind="stable")[:k]

Scores are for ranking, not for trusting

The most important thing I learned about this model is that a words-to-photo score only means something next to other scores for the same words. A 0.3 for "rings" isn't the same as a 0.3 for "cake". So MythiCull never tells Meera "80% match". It only puts photos in order.

The mood pick follows the same rule. Inside a burst, it ranks the photos once by sharpness and once by mood, and then blends the two rankings rather than the raw scores:

sharp_rank = {p["id"]: r for r, p in enumerate(sorted(g, key=lambda p: -sharp(p)))}
vibe_rank  = {p["id"]: r for r, p in enumerate(sorted(g, key=lambda p: -score(p)))}
return min(g, key=lambda p: (1 - weight) * sharp_rank[p["id"]] + weight * vibe_rank[p["id"]])

Photo-to-photo scores are much steadier, so bursts can use a fixed cutoff. I tested it on 354 public HDR+ frames from 40 exposure-bracket bursts, with synthetic capture times. Photos from the same burst scored between 0.973 and 0.999, while photos from different moments scored between 0.54 and 0.68. Cutoffs from 0.85 to 0.94 produced 39 groups against 40 source bursts, and MythiCull uses 0.92. These were easy bracketed frames, not a moving-subject wedding shoot; the threshold still needs validation on that kind of material.

Small things that matter

No float16. It can break this model's numbers, so MythiCull uses float32 on a CPU and bfloat16 on a supported GPU, falling back to float32 when needed.
Indexing can stop and restart. Progress is saved after every batch. If Meera's laptop dies halfway through, it picks up where it left off.
Nobody waits for the AI. Culling can start right after import. Time-based chapters are available after import; analysis adds similarity groups and suggested names, while search uses the indexed photos.
Two cameras, one timeline. If a second shooter's camera clock is a few minutes off, Meera can set an offset for that camera model and the day lines up again. The original photo time stays untouched. Two bodies of the same model currently share one offset.

Why Does Open Innovation Matter?

It's someone's wedding. These photos show families, kids, and guests who never signed up for an AI service. With MythiCull nothing is uploaded, there's no account, and there's no tracking. The photos stay with the person the couple trusted.
It works where photographers are. Meera can cull on the train home or in a hotel with bad wifi, and she never waits for an upload bar.
It keeps the price fair. A hosted model charges for every photo it looks at, which adds an ongoing operating cost. An open model on the photographer's own computer only costs electricity.
No one can take it away. The model is a folder on the photographer's disk. If a company raises its prices or shuts a model down, MythiCull keeps working the same way it did on day one.
I could control every step. With open weights I could pick the right number format for each kind of device, use the model's own search prompt, and tune the burst cutoff myself.
Where a closed model would win: a big hosted vision model might name chapters better, and it might judge facial expressions better too. But it would put an upload, an account and a bill between a photographer and their own work. For a tool that sees every photo of someone's wedding day, I don't think that trade is worth it.

What's Next

Validate the XMP sidecars in Lightroom Classic and darktable.
A one-click installer, so a photographer never has to open a terminal.
Validate burst suggestions and description-based picks on a real moving-subject shoot, and time an actual photographer's cull.

Prize Categories

Best Use of Gemma: EmbeddingGemma 2 is the only model in MythiCull, and it does four jobs: burst groups, plain-English search, the mood pick, and chapter names. It runs on the photographer's own computer (float32 on a CPU, bfloat16 on a supported GPU, with float32 fallback), is downloaded once, and then works offline.

If you know a wedding photographer, or you are one, I'd love to hear what it would take to trust a tool like this with a real cull.

Kokishin: an offline Android app that turns everyday oddities into small mysteries

Rupam Das — Mon, 12 Oct 2026 06:59:50 +0000

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

What I built

Kokishin is an Android app that turns everyday outdoor details into small mysteries you solve by walking around and looking closely.

You photograph something odd: a worn bench, a dirt shortcut across the grass, moss on only one side of a wall. An on-device Gemma 4 model turns the photo into a case:

a mystery question
2-3 possible explanations
a real-world check for each one

Then you go outside, collect evidence (photos or notes), write a conclusion, and the AI critiques your reasoning. It never reveals the answer. It asks questions, suggests possibilities, and sends you back outside.

The idea comes from the everyday-mystery spirit of the anime Hyouka.

Why the screen should be the shortest part

Nature apps tell you what something is. Nothing helps you ask why it is that way, and answering that takes looking, walking and coming back later. That is a natural reason to touch grass.

So the app is built to get out of the way:

One main action per screen.
One "Your first check" card, with the other possibilities behind a tap.
Every case records time spent investigating versus time on screen, and shows the split once you solve it.

Why open-source AI matters here

Offline. It works in parks and on trails with no signal. After a one-time model download, the whole loop works in airplane mode.
Private. Photos of your street and routes never leave the phone.
Free. No API costs or rate limits, for you or for me.
Controllable. I decide exactly how the model behaves, so it never spoils the answer. That rule lives in the prompts, not in a server I don't control.

There are no cloud calls at all. The only network use is downloading the model files on first launch.

How it's built

Expo + React Native + TypeScript, Expo Router, as a development build (Expo Go can't load native modules like this).
llama.rn running Gemma 4 E2B (GGUF) plus its mmproj vision file, so the model can read the photo.
expo-image-picker (camera only, no gallery), expo-image-manipulator to shrink photos before inference, expo-file-system for the resumable model download.
Cases saved with AsyncStorage.
Every prompt lives in one file, src/ai/prompts.ts, and the model's JSON output is parsed with hand-written type guards. If parsing fails, it retries once and then returns a typed error instead of crashing.
The release APK is built with EAS Build.

Demo

Download the APK from here and install it on an Android phone (8 GB RAM recommended). The release APK is about 183 MB, and the app downloads the model files on first launch, so use Wi-Fi.

Code

ru-das / kokishin

Kokishin is an offline Android app that uses an on-device Gemma 4 model to turn everyday outdoor oddities into small mysteries you solve by going outside and gathering evidence. Built for the Hacktoberfest 2026 Open-Source AI Challenge: Week 1.

Kokishin

Turn everyday outdoor oddities into small mysteries, then go outside and solve them.

Kokishin is an Android app for the dev.to challenge Build something with open-source AI at its core (theme: Touch Grass). Photograph something odd, like a worn bench, a dirt shortcut or moss on one side of a wall. An on-device Gemma 4 model turns it into a case: a mystery question, 2-3 possible explanations, and a real-world check for each. You collect evidence outside, write a conclusion, and the AI critiques your reasoning. It never gives away the answer.

The screen is meant to be the shortest part of the experience. The app measures investigating time versus on-screen time for every case.

Screenshots

Home	Settings

New Case	Case

How it works

Home: your saved cases and the "I'm curious!" button.
New case: take a photo (camera only) and optionally say what caught your eye.
Case:…

View on GitHub

Screenshots

Home	Settings

New Case	Case

What's next

I'd like to investigate why the APK is as large as it is (most likely the llama.rn native libraries), and add a custom icon and splash screen.

Prize Categories

Best Use of Gemma: Gemma 4 E2B is Kokishin's only AI, and it runs entirely on the phone through llama.rn. Using its vision file (mmproj), it reads your photo of something odd and turns it into a case: a mystery question, 2-3 possible explanations, and a real-world check for each. Later it critiques your written conclusion. The rule is that the AI asks and suggests but never reveals the answer, and it works offline in airplane mode.

PYQed: I built the exam tool my friend needed, with Gemma 4

Rupam Das — Mon, 05 Oct 2026 06:58:42 +0000

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

What I Built

Everytime exams come up, my friend Subhadip and the entire class panics. They hop into their WhatsApp group (our holy repository) and browse through PDFs of previous year questions (PYQs).

There's a huge collection of question papers, but no idea about what to study.

Which chapters are the most important ones?
What are the maximum-marking questions?
Are these questions repeated?

We usually take a guess, or randomly refer to a curated list of important questions that some random higher year student has given us.

When Subhadip had an exam, and my friends continued to pull the same stunt, I thought, why don't we make something that can do this for us?

So, I built PYQed for Subhadip and others, taking the syllabus and previous year question papers and converting them into a question bank organised by topic and marks.

Features

Your syllabus becomes subjects automatically. Import the syllabus PDF and PYQed creates a folder for each subject, with its units and topics. One can edit freely, and you can even create subjects manually.
It reads scanned papers. Most PYQs are images exported as PDF. Gemma 4 reads each page, extracts each question with its number, marks, and type, and you can review them beside the original page before saving.
Each question is filed under its syllabus topic, marked as the number of marks and sorted by how often they have appeared before. "Asked 3× (2019, 2021, 2024)" appears on the card.
Units are prioritized based on actual weight, such as average marks per paper, so that one knows where to begin.
Practice mode shows questions from topics chosen and those marked "Revise" appear more frequently.
One imports, all benefit. A subject exports as a tiny JSON file you can WhatsApp. Anyone who opens it obtains the complete analysis without needing an account or key.

Subhadip's Reaction

I sent Subhadip the APK and a DSA JSON file I'd already analyzed. A few minutes later, he called me and said

Wait, this question has come up three years in a row and nobody told us? And Unit 3 is worth more than the other two put together?

After that he tried and app by himself, and used the practice mode. His verdict was

Bro where were you all this time? Share it to the rest ASAP!!

Demo

Install and try the app here

YouTube Video: https://youtu.be/vQk791GQyJ8

Screenshots

Home	Syllabus review	Paper review

Topic view	All questions	Practice

Code

ru-das / PYQed

PYQed

Turn your university syllabus and past year question papers (PYQs) into a topic-wise question bank you can sort, filter and practise.

Powered by Gemma 4, an open-weight model from Google DeepMind.

Built for the DEV.to Hacktoberfest Weekend Challenge 2026, theme "Build for a Friend". Built on a 4 GB RAM laptop with no GPU, no server and no budget.

Download

Get the Android APK from the latest GitHub Release. On iPhone, run it through Expo Go (see Setup).

Screenshots

Home	Syllabus review	Paper review

Topic view	All questions	Practice

The problem

Before exams, students skim years of PYQs trying to guess what matters, or trust unverified "suggestions" from seniors. PYQed answers it with data: which units carry the most marks, and which questions keep coming back.

It works for any university's syllabus and paper format. Nothing is hard-coded to one university.

What it does

Create subjects…

View on GitHub

How I Built It

No server at all

PYQed has no backend. The app speaks directly to Gemma 4 using the user's own free Google AI Studio key, kept secure on the phone. Getting one only needs a Google login and one button. The app can also use OpenRouter or any OpenAI-compatible endpoint, set in Settings. Everything else is on the phone, like reading PDFs with pdf.js in a hidden WebView, storing subjects, ranking, sorting, and practice. It works offline once imported. It's built with Expo (React Native + TypeScript), tested live in Expo Go, and compiled into an APK in the cloud with EAS, because my laptop (4 GB of RAM, a Pentium, no GPU) can't run Android Studio, let alone a model.

A rule: AI reads and labels, code counts

In an early test, Gemma 4 invented a heading that wasn't on the page. That influenced this whole app. Gemma has three jobs and each returns JSON that my code validates:

Read the syllabus into subjects, units, and topics.
Transcribe each paper page into questions, copying text exactly, never solving or rephrasing. If marks aren't printed, it's required to return null , not a guess.
Label each question with a topic ID from the syllabus. Everything else is code: marks per unit, times asked, priority, sort order, and even finding repeats (same wording in at least two different years). No number in PYQed comes from an AI; repeats used to be an AI call, but that cost extra requests in a free quota, and could only match wording anyway, so it's done for free in code. Since no model is perfect, the app never fails silently either: unreadable marks show as "? marks", numbering gaps get flagged, and every question is reviewed next to the original scanned page before it's saved.

What went wrong

A finished answer was thrown away. A table-heavy syllabus took 4‒7 minutes, then failed when "request took too long" while AI Studio's usage page showed the tokens had been generated. My 5-minute timeout had cut Gemma off mid-thought. Now the response is streamed and the app only gives up after 90 seconds of silence.
Gemma got stuck in a loop. The streamed thinking showed it repeating a "Final Check" that topic details were copied exactly. My prompt said to copy exactly plus a ~15 word limit, which can't both be true. The prompt fixed the loop.
Google stopped answers halfway. Its copy filter ( RECITATION ) cut off syllabus answers at the same spot twice, and I was throwing away the good part and starting again. Now the complete part is kept, and only the rest is asked for.
Everything was "Unassigned". The review screen marked any edited question as user-edited, and the topic labeller skipped those, so reviewed papers never got labelled. Failures were also silent. Now the real error is shown.
PDF imports hung forever because the importer held an old handle that still thought the PDF reader wasn't ready.
You can't steer a model's thinking with a prompt. My first attempt at telling Gemma how to think made it dump its outline into the answer. "Think briefly, decide once," plus a few tie-breaker rules, worked better.

I built the first structure with Antigravity CLI from a spec I wrote, and used Claude Code to find and fix bugs like the ones above. Every design decision, and every test on a real phone, was mine.

Why Does Open Innovation Matter?

Because the whole thing runs for ₹0 and without a server. I've no budget and a 4GB laptop. Gemma 4's free tier is the reason a student can build this at all, and why Subhadip and the class can use it without paying anyone. My first hosting plans died on paywalls; an open model with a free key never hit one.
Because I can swap the model without rewriting the app. PYQed defaults to gemma-4-26b-a4b-it (faster) and lets you switch to gemma-4-31b-it (larger), OpenRouter, or any OpenAI- compatible server. If Google changes its free tier tomorrow, classmates change one setting. Someone with a spare PC can point the app at their own LM Studio or vLLM and keep their papers off other people's servers entirely.
Because students' papers and syllabi stay theirs. There's no PYQed server and no account. Pages go to the chosen provider only during import. Subjects, practice progress, and shared files live on the phone, and an exported file never contains an API key.
Because open models are moving toward the device. Today PYQed uses a hosted model to read papers, but nothing in its design depends on that. As phones and open models meet in the middle, the reading step can move onto the phone without rewriting the app.

What's next?

A shared library of analysed subjects per university, so most students never import anything.
Practice variants with changed numbers, and checking photographed solutions, both of which need much more careful verification than a weekend allows.
Reading papers fully on-device as small models improve.

Prize Categories

Best Use of Gemma: Gemma 4 is PYQed's default AI. It reads syllabi and scanned papers and labels topics, all under the "AI reads and labels, code counts" rule.