DEV Community: Faris Daffa

Touch Soil: an offline garden planner with Gemma running in your browser

Faris Daffa — Wed, 07 Oct 2026 06:36:41 +0000

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

What I Built

Touch Soil is a garden planner that tells you what to plant this week, and it runs entirely in your browser. You pick your climate zone, optionally mention what you already grow, and an open-weight Gemma model writes a weekly plan: what to plant now, the one job worth doing, and the thing you should skip.

No account. No server. Nothing you type ever leaves your device, because there is no "elsewhere" to send it to. After the first model download, it works with the internet unplugged, which is exactly where a garden usually is.

I built it for this week's theme, Touch Grass: the whole point is that the screen part is short. You open the page, read a plan that takes one minute, and go put your hands in the soil.

Demo

Deployed app: https://touch-soil.onrender.com

Note for first load: the Gemma weights (about 1 GB) download once into your browser cache, then load locally from disk. You need a browser with WebGPU (recent Chrome or Edge).

Code

Repo: https://github.com/faris0520/touch-soil

Faris0520 / touch-soil

An offline garden planner with Gemma running in your browser

Touch Soil

An offline garden planner: you pick your climate zone, and an open-weight Gemma model running entirely in your browser (via WebLLM) writes a "what to plant this week" plan. No server, no account, and your garden data never leaves your device.

Why open

Runs with no internet after the first model download: WebGPU inference in the browser, so it works at the garden, on a trail, or anywhere the signal doesn't.
Data stays local: the zone you pick and what you're growing are never sent anywhere; there is no backend at all.
Everything is swappable: the climate data is a small JSON-style table anyone can fork and correct (frost-date datasets are US-centric, so this one includes tropical wet/dry seasons too), and the model is one string away from being any WebLLM-supported open-weight model.

How it works

Engine picker. Two ways to run the same open-weight…

View on GitHub

The interesting files:

src/data/climates.ts: the climate table. Nine zones, from USDA frost zones to tropical monsoon seasons.
src/lib/planner.ts: the prompt, the JSON schema, and the deterministic offline guide.
src/lib/llm.ts: model selection and the WebLLM engine setup.

How I Built It

The stack is deliberately boring: Vite, React, TypeScript, plain CSS. All the novelty is in how the AI piece works:

You choose where the model runs. A picker offers two engines for the same open-weight Gemma: downloaded into the browser (WebLLM), or an Ollama server on your own machine. The Ollama path only detects models you have already pulled; it never downloads anything by itself. This also gives browsers without WebGPU a real AI option.
Heavy actions ask first. Before the first browser download (about 1 GB) and before sending your garden details to the local Ollama server, a confirmation panel explains exactly what is about to happen.
The model runs in the browser. WebLLM runs open-weight models on your GPU through WebGPU. The app picks the smallest Gemma available in WebLLM's prebuilt list (Gemma 3 1B, quantized) and caches it after the first download.
The model cannot break the format. Small models love to ignore instructions, so instead of trusting prompts I constrain decoding: WebLLM gets a JSON schema via response_format, Ollama gets the same schema via its format parameter. The model can only emit { plants: [{ name, why }], task, skip }, and the UI renders that structure itself. My first free-form version produced headings like "Plant now (3)" and a greeting, the constrained version cannot.
The climate facts are plain data. Frost-date planners assume USDA zones, which is unhelpful if your garden has a wet season instead of a winter. Touch Soil bundles a small table: four temperate bands, tropical lowland and highland (monsoon wet/dry seasons), arid, and Mediterranean. It is intentionally small and honest about being approximate, and it is a JSON file you can fork and correct for your region.
There is a no-AI fallback. If neither engine can run, a rule-based guide written from the same dataset takes over. The app is never empty.

One war story from the build: Gemma 3's prebuilt WebLLM record ships both a context_window_size override and a sliding_window_size base config, and the engine refuses to start with both active. The fix (the engine tells you this, to its credit) is switching the record to sliding-window mode with attention_sink_size: 0.

Why Does Open Innovation Matter?

For this project, the open pieces are not a detail, they are the whole argument:

It works where the garden is. No signal, no problem: once cached, the in-browser model runs offline, and the Ollama engine only ever talks to your own machine. A closed API would make the app useless exactly when and where it should be most useful.
Your garden stays yours. What you grow, your zone, your questions: none of it reaches a cloud. The Ollama engine even shows a confirmation naming the exact server your details will go to, and the WebLLM engine shows one before its one-time download.
You can swap the brain. The model is one string in src/lib/llm.ts. Want a bigger Gemma, a different open-weight model WebLLM supports, or another local Ollama model? Change a filter or type a name. Want better climate data for your region? Edit a JSON table and open a pull request.
It costs nothing to run. No API bill per plan. The compute is the device you already own.

Prize Categories

Gemma (the planner runs on an open-weight Gemma model in the browser)
Render (the app is deployed on Render: https://touch-soil.onrender.com)

My friend rambles in interviews, so I built him Unramble

Faris Daffa — Sat, 03 Oct 2026 14:41:30 +0000

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

What I Built

My friend, Agus, has a problem I recognized because I have it too. He knows his stuff. Ask him about a project he shipped and, on paper, the answer is all there. But ask him out loud, in an interview, and the answer wanders: it starts three digressions deep, never lands the result, and buries the one sentence that mattered somewhere in the middle. He is not a weak candidate. He is an unpracticed one, and practice is exactly the thing he cannot do, because practicing means saying half-finished answers out loud to another human, at night, repeatedly, until it stops being embarrassing.

So I built him Unramble: a practice partner for real interviews that runs entirely on his laptop. He pastes a job description and a few CV bullets. Gemma 3, running locally through Ollama, writes seven interview questions tuned to that role. He answers out loud, into the microphone. Whisper, running locally inside the app's own server, transcribes him. And then the part he actually needed: the report.

Every sentence of his answer gets a color that says what job it was doing: blue set the Situation, purple named the Task, green carried the Action, yellow landed the Result. Gray is filler. He can literally watch an answer go green, green, gray, gray, gray, and never reach yellow. Below the transcript: relevance and conciseness scores, STAR coverage, a "tangled" meter computed from measured filler density and sentence length, and a rewritten version of his own answer with the detours removed, keeping only his real facts. Any question can be re-answered on its own and rescored, so the weak one gets drilled until it stops being weak.

One rule shaped the whole build: nothing he says ever leaves his laptop. The recordings live in browser tab memory and are never written anywhere. The transcript, the scores, the report: all in local storage. The models run on his machine. There is no server to upload to.

Demo

https://unramble.farisdaffa.in

Code

GitHub: Faris0520/unramble

Faris0520 / unramble

A practice partner for real job interviews that runs entirely on your laptop.

Unramble

A practice partner for real job interviews that runs entirely on your laptop.

Unramble was built for one real person: a friend preparing for interviews whose answers know all the facts but fall apart in the telling. You speak an answer out loud, and the app shows the structure behind it: which sentence set the scene, which one carried the action, where you drifted into filler. Then Gemma rewrites the answer, straight.

Everything is local. Questions and scores come from Gemma 3 4B through Ollama Transcription comes from Whisper through transformers.js, inside the app's own server Recordings live in browser tab memory and are never written anywhere. There is no server to upload to, so an interview rehearsal stays as private as it should be.

Quick start

One-time setup (details in SETUP.md):

winget install Ollama.Ollama
ollama pull gemma3:4b

Then:

npm install
npm run build
npm start

Open http://localhost:3000…

View on GitHub

How I Built It

Three open-source pieces, glued together as one local pipeline:

Question generation and scoring: Gemma 3 4B via Ollama. The app talks to Ollama's local REST API with structured output (a JSON schema Ollama enforces), which is how a 4B model stays reliable: generation returns exactly { questions: string[7] }, and scoring returns sentence tags plus integer scores, every time, on a laptop CPU. The model tag is one environment variable, so he can swap in a bigger Gemma when his hardware allows.
Transcription: Whisper via transformers.js. The browser records the take, decodes it with its own AudioContext, mixes to mono, resamples to 16 kHz, and hands the app's server a plain PCM WAV. The server runs the quantized Whisper model in-process; the weights download once into the project folder and work offline from then on. For Indonesian answers, an environment variable switches to the small model, which hears the language better.
The metrics that do not need a model at all. Filler counting, sentence splitting, and the tangled score are computed in plain TypeScript from his actual answer. A model judges structure; the app measures facts. The report never shows a number that was not measured.

Two details I am proud of. First, the transcript is editable before scoring: if Whisper misheard a word, he fixes it, and the score is computed on what he approved, not on what the machine guessed. Second, the on-screen checklist: the setup page pings Ollama, sees exactly which local piece is missing, and prints the one command that fixes it. A friend who would rather not debug a local stack by hand gets that command with a Copy button.

The interface follows Notion's design system, on purpose: a report about your weakest answer should read like a calm document, not a dashboard. Pastel tints carry the sentence structure, purple is reserved for the one action per screen, and the same layout works on a phone, because practice happens wherever the laptop opens.

Why Does Open Innovation Matter

An interview rehearsal is the most private thing a job seeker does. You say half-finished sentences. You forget words you know. You ramble, and you know you are rambling while it is happening. Nobody would want a recording of that on somebody else's server.

That is the argument for open, local AI in this specific product, and it is not a technical argument, it is a dignity argument. With a closed API:

his voice and his weakest answers would sit in someone else's cloud, on someone else's retention policy;
every practice rep would cost money, and the whole point of practice is unlimited reps;
it would need the internet, and the moment he most wants to practice is 2 AM before a morning interview, when he just needs the thing to work.

With the open stack, the privacy story is inspectable instead of promised. The Ollama process runs on his machine, on a port he can see. The model weights sit in a folder he owns. If he wanted, he could read every line that touches his voice. And because the core is open, the app can grow with him: swap the model when a better open one lands, fine-tune on his own practice answers someday, run it forever at zero cost on hardware he already owns.

Open innovation also meant I could build this in a weekend and hand it to one specific person, with no API budget, no accounts, and no server to maintain. The tool exists because one real friend needed it, and it can keep existing on his laptop whether or not I ever touch it again.

Handing it over

Handover happened on his actual laptop, in his room, with the setup page doing its job: he installed Ollama, pulled the model, and watched the checklist tick green one piece at a time. He is a computer science student, so halfway through the download he asked what exactly was running on his machine. That question is the reason this app is local, and this friend is the one person I could not answer with trust me. So I opened the folders instead: model weights in a directory he owns, transcript and scores in local storage, recordings that are never written anywhere. He can read every line that touches his voice. Most people have to take that on faith. He can just check.

Then I handed him the microphone and sat where he could not see me, because a first take needs an audience of nobody. He pasted a junior developer posting he had actually applied to, answered the first question out loud, and produced the answer he always produces: every fact present, one long green Action doing most of the talking, the yellow Result arriving late and out of breath. The tangled meter flagged it without mercy. The moment that mattered came when the rewrite rendered, though. The app had kept only his real facts and cut the detours, and he read his own answer, straight, and said the thing this whole project was built for: oh. That is what I meant.

He drilled the weakest question again that night, on his own, with me out of the room. I know because a screenshot of the second report arrived later with no caption: same question, less gray, the yellow landing where it belongs. That screenshot is the best evidence this project has produced, because it shows the tool in its natural habitat: 2 AM, one nervous person, one laptop, no budget, no account, no me. He is a computer science student. If he ever wants to make it better, he can read the code and change it. That was always the real handover: not a service I keep alive for him, but a folder of open pieces he fully owns.

Prize Categories

Gemma

Thanks to the open-source projects it stands on: Gemma, Ollama, Whisper, and transformers.js.

Hi there! Welcome to my Dev.to profile

Faris Daffa — Wed, 25 Sep 2024 23:23:41 +0000

Hello, welcome to my Dev.to profile /.\

I'm Faris Daffa, 18yo, i live in Jambi City, Indonesia.

I am currently an undergraduate student at Computer Science or Informatics, Faculty of Science and Technology, Jambi University.

Nice to meet ya!

26/09/2024