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
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…
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.
Top comments (2)
Very nice! I have been thinking about the fridge-photo use case a lot, because I am also lazy 😂
Welcome to The Lazy Company! 😂🤝