DEV Community: Aditya Kumar

Make your commits more valuable by gardening digitaly on Moss Garden it's Built for laze devs like me who frequently pushes code instead of spamming to make the contribution graph look more greener instead grow your own garden and proudly own it

Aditya Kumar — Mon, 26 Oct 2026 06:29:58 +0000

Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady Submission 🦥

Aditya Kumar

Oct 23

Slow and steady, a little lazy: I built a garden that grows from small commits

#devchallenge #hf26challenge #ai #opensource

12 min read

Slow and steady, a little lazy: I built a garden that grows from small commits

Aditya Kumar — Fri, 23 Oct 2026 11:30:26 +0000

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

Why I Built It

I kept coming back to one question: why does a tool that is supposed to celebrate software development make people feel guilty for not developing software every single day?

A contribution graph is useful. It gives you a visual history of your work. But the moment you start protecting the green squares instead of enjoying the work behind them, the incentive has quietly changed. You start optimizing for activity rather than consistency, and consistency rather than well-being.

I wanted to build something that rewarded the behaviour I actually wanted to encourage: returning to a project, making a little progress, and being comfortable walking away when life gets busy.

That led to three rules I treated as product requirements, not optional features:

Progress must be permanent. XP is lifetime progress. A quiet week must never erase what someone has earned.
Consistency must beat intensity. The game should make several small sessions more rewarding than compressing all your activity into one night.
Rest must not require permission. There should be no streak to save, no deadline to beat, and no punishment waiting when someone returns.

These rules shaped the game mechanics, the backend, the AI integration, and even the way the application handles deployment failures. If a model is unavailable, the garden should still grow. If someone disappears for a month, their garden should still be there.

Moss Garden is my attempt to make a developer productivity tool that doesn't turn productivity into another source of pressure.

What I Built

It is 11:52 PM. You are tired, the bug can wait until morning, but a small green square on your contribution graph is about to turn grey. So you push a typo fix you do not care about, just to keep the streak alive.

Most developers know that feeling. A tool meant to celebrate your work quietly turns every missed day into a small loss. I wanted the opposite: something that is glad when you show up, and does not punish you when you don't.

So I built Moss Garden, a slow-productivity game for developers. You sign in with GitHub, pick the repositories that count, and every small commit you author grows a hand-drawn garden of moss, ferns, flowers and a young maple.

The garden keeps everything it grows. XP never goes down, there are no streaks to protect, and nothing resets.

The laziness it rewards: showing up a little, on a few days, and ignoring the rest.

Each commit is worth less the more you push in one day (1x, 0.5x, 0.25x, then 0.1x), and daily XP caps at 40. Ten commits at midnight are worth barely more than three.
Four cared-for days in one week earn a one-time steady-week bonus that a single all-nighter cannot.
Take a week off and vitality only settles to a floor. Plants never wilt. Come back after a month and it is all still there, waiting, with a "Came back" badge to say welcome home.

Anyone who has felt a contribution graph turn a missed day into a loss gets to be a little lazier here. After sign-in there is nothing to log. A nightly sync does the remembering, and an optional AI gardener writes you a short journal each week about what grew.

The idea is simple: your garden should reflect the work you have done, not the days you failed to show up.

Demo

Live: https://moss-garden-api.onrender.com/

You do not need to sign in. Press Explore a demo garden on the home page and wander around.

A few corners of the garden:

Code

ADITYA-KUMAR-2358 / Moss-Garden

A cozy garden that grows from your GitHub commits. Small, steady commits earn XP, plants, badges and seasons; all-nighters wither it, and missed days never reset it. Commit quality, plant names and a weekly journal come from Gemma 4, an open-weight model.

Live site · Product · Game rules · Architecture · Design system · Deploy · For coding agents

Moss Garden

A slow-productivity game for developers. Sign in with GitHub, pick the repositories that count, and every small commit you author grows a hand-drawn garden of moss, ferns, flowers and a young maple. The garden keeps everything it grows. There are no streaks to protect, no countdowns and nothing to lose.

Built for the DEV Hacktoberfest challenge "Slow and Steady: build something with open-weight models or open-source AI that rewards laziness."

Why

Contribution graphs and streak counters reward intensity. A missed day feels like a loss, a 2 a.m. push feels like a win, and the first broken streak is often the last day someone shows up. Moss Garden flips that:

Steady beats loud. Each commit is worth less the more you push in one day, and daily XP is capped…

View on GitHub

How I Built It

The rule I set myself: the garden has to be trustworthy first, and clever second.

Open-weight model: Gemma 4 through Backboard. google/gemma-4-26b-a4b-it names new plants and writes the weekly journal, the little touches that make a garden feel like yours.

It is opt-in. It is off for every player until they switch it on, and off on the server until a request budget is set.
It only sees garden counts, the season and plant species. It never sees code, repository names or commit messages.
Model output is treated as untrusted. It is parsed against a strict schema, and a failed call falls back to plain rule-based text instead of lowering anyone's score.
A daily request budget keeps calls within a small credit.

The game itself is deliberately not AI. XP, levels, vitality, plant growth and badges live in a pure Python rules engine with 409 pytest cases. A game people trust needs rules that behave the same every time, so the model only adds words and names. It never decides what you earned.

How the garden actually works

The important engineering decision was to keep the rules deterministic. A garden should not award different XP because a language model had a different answer on Tuesday.

The flow is deliberately simple:

Connect GitHub. The player signs in and selects the repositories they want Moss Garden to consider.
Synchronize activity. A scheduled backend job fetches eligible commit activity, so the player doesn't have to manually record anything.
Apply the rules. The Python game engine calculates XP, levels, vitality, plant growth and badges from the activity and the game's rules.
Persist the result. The backend stores the garden's state so the experience can continue across sessions.
Present the garden. The React frontend turns that state into a visual space with growing plants, seasonal changes, earned badges and a weekly journal.

GitHub is the source of activity, the rules engine is the authority on progress, and the frontend is how that progress becomes something you can see.

The frontend doesn't need to understand how XP is calculated, and the model doesn't need access to the database or the player's source code. Each layer has a narrower job, which makes the system easier to test and reason about.

The mechanics behind slow productivity

The rules are deliberately biased toward distributed effort rather than raw volume.

Player behaviour	Game response
First eligible commit of the day	Full XP weight
Second commit on the same day	Half XP weight
Third commit on the same day	Quarter XP weight
Further commits that day	Diminishing returns, down to 0.1x
Daily progress	Capped at 40 XP
Activity across four days in a week	One-time steady-week bonus
A quiet week	Vitality settles to a floor; earned progress stays

The numbers are not meant to measure the quality of someone's code. They are a game mechanic designed to make a particular habit feel rewarding: show up, make progress, and leave when you're done.

The cap also prevents a large burst of activity from dominating the garden. A developer who makes a few small commits across several days can still earn the steady-week bonus that a single all-nighter cannot.

The distinction I care about most is this: the game can slow down without taking anything away.

The technology stack

Stack: React 19 + Vite on the front, FastAPI + SQLAlchemy 2 + Alembic on the back, PostgreSQL in production and SQLite locally. The art is layered illustration, with light and dark themes and prefers-reduced-motion respected everywhere, because a calm game should be calm for everyone.

Each part has a specific responsibility:

Component	Responsibility
React 19 + Vite	Renders the garden, handles interactions and presents the player's progress
FastAPI	Exposes the application API and coordinates backend operations
SQLAlchemy 2 + Alembic	Handles database access and schema migrations
PostgreSQL	Persists production data
SQLite	Simplifies local development
Python rules engine	Calculates XP, levels, vitality, plant growth and badges
Backboard + Gemma 4	Generates optional plant names and weekly journal entries
GitHub Actions	Handles keep-alive and scheduled synchronization workflows

The stack is not just a list of technologies. Each part has a boundary, and those boundaries are important to keeping the experience predictable.

I also kept a docs/ directory alongside AGENTS.md. The repository documents the product requirements, game rules, architecture, design system and implementation decisions.

That documentation serves two audiences: a developer opening the repository for the first time, and a coding agent that needs to understand the existing constraints before changing anything.

The goal is that someone should be able to pick up Moss Garden without relying on a conversation with the person who built it.

Deployment on Render

Render: render.yaml creates a free Docker web service and a free Postgres database. The container runs migrations, then starts the server. Free-tier limits shaped the design, and I leaned into them:

A free web service sleeps, so a GitHub Actions keep-alive workflow pings it.
Render cron jobs are not free, so a second GitHub Actions workflow calls POST /api/jobs/nightly with a bearer secret for the nightly sync.

This keeps the scheduling logic separate from the application process. The nightly sync can run independently, without requiring someone to open the website.

The free hosting tier still comes with trade-offs, including cold starts and resource limits. The workflows help work around those constraints, but they do not eliminate every hosting limitation.

Sound and accessibility

ElevenLabs: the soft sound effects and ambience were generated with ElevenLabs once and shipped as static files, so there are no runtime calls and no key in production. Sound is off by default, never autoplays, and every sound has something on screen too. The journal can be read aloud with the browser's speech. An ElevenLabs narration client is written but not switched on yet.

I wanted the sensory details to support the experience without demanding attention. Sound should be an invitation, not something the user has to fight to disable.

The same principle applies to motion. The garden uses layered illustrations, light and dark themes, and respects prefers-reduced-motion. A slow-productivity tool should not force everyone into the same visual experience.

Testing the Idea, Not Just the Interface

A garden can look convincing while quietly breaking the promise behind it. The difficult cases aren't whether a flower renders or whether a button responds. They're whether the rules remain fair when activity is irregular, synchronization happens more than once, or the AI feature is unavailable.

I built the rules engine separately so that its behaviour could be tested without relying on a live GitHub account, a running frontend or a language model.

The backend test suite contains 409 pytest cases. The core rules are particularly important because they determine whether the experience remains consistent over time.

Some of the behaviours worth testing are:

Diminishing returns: additional commits on the same day must receive the intended lower XP weights.
The daily cap: repeated activity must not push daily XP beyond the defined limit.
The steady-week bonus: the bonus depends on activity across distinct days, not simply a large number of commits.
Permanent progress: inactivity must never subtract lifetime XP or remove established plants.
Plant progression: growth and unlocks must follow the rules rather than the wording generated by the AI.
AI failure: an unsuccessful model request must not change game state or prevent the rule-based fallback from working.

These are the kinds of invariants that make the experience trustworthy. A visual regression is easy to notice; a subtle scoring bug can go unnoticed while quietly undermining the entire idea.

The tests are not proof that every real-world GitHub edge case has been covered. They are a way to make the core rules explicit, repeatable and safer to change as the project evolves.

For me, this is also where the project became more than a frontend experiment. The illustration makes the garden inviting, but the rules and their tests are what make it fair.

Why Does Open Innovation Matter?

Moss Garden reads your commit history, which is personal. Open weights made three things possible that a closed API would not:

Trust you can inspect. The code is public, the rules are documented, and the model is an open-weight Gemma 4 with a permissive licence. The model only receives counts and species, and because the weights are open, anyone could run it locally so nothing leaves their machine.
A promise that outlives a vendor. The game promises that nothing resets. That promise should not depend on a hosted model version being deprecated. The garden works with the AI fully off, and the model is a swappable setting behind one Backboard key.
Cost control on a small budget. Running a capable open model through one key, with a request budget, made an always-gentle feature affordable for a solo project.

There is also an important distinction between an open-weight model and a fully local deployment. Moss Garden currently uses Gemma 4 through Backboard. The model's open weights provide another path for future deployments, but the current hosted integration is not the same as running inference locally.

That distinction matters because privacy should be explained through the actual data flow, not simply through the name of the model.

The application needs GitHub activity to grow the garden. The optional AI gardener receives a deliberately narrower set of information: garden counts, the season and plant species. It does not receive source code, repository names or commit messages.

The AI is there to add personality, not to become the authority over the user's progress.

The Lazy Payoff

The saved effort is attention, not hours. There is no logging, no habit to maintain and no streak to defend. You sign in once, commit as you normally would, and open the garden when you feel like it.

Close the laptop at 11:52 PM. Take the weekend. Take the month. When you come back, the moss will still be there, a little greener than you left it.

What It Can't Do Yet

Moss Garden is a working project, not a claim that productivity has been solved. There are a few limitations worth being honest about.

It measures activity, not engineering quality. A commit is a signal that work happened, not proof that the work was valuable. The game cannot reliably judge the difficulty, impact or craftsmanship of a change, and it shouldn't pretend to.
Synchronization is not instantaneous. Activity is collected through the scheduled synchronization workflow. A newly pushed commit may not appear in the garden immediately.
The free hosting tier has trade-offs. Render's free web service can sleep when idle, and the database has its own free-tier constraints. The keep-alive and nightly-sync workflows help with availability and scheduling, but they don't eliminate every hosting limitation.
The AI gardener depends on configuration and availability. Gemma 4 is optional. If the feature is disabled, its request budget is unavailable, or a request fails, the application must fall back to ordinary rule-based text rather than making the game dependent on the model.
The deployed AI integration is hosted. Gemma 4 is an open-weight model, but the deployed application calls it through Backboard. Running the model locally would require a suitable local inference integration; open weights alone don't make the current hosted implementation local.
The garden is a model of progress, not a replacement for your workflow. It doesn't manage tasks, review pull requests or tell you what to build next. Its job is to give your existing development activity a gentler visual home.

These limitations are part of the design conversation, not reasons to abandon the idea. I would rather ship a small, understandable system with clear boundaries than claim that a garden can measure everything that matters about software development.

Prize Categories

Render: free Docker web service and Postgres from a single render.yaml, with GitHub Actions covering keep-alive and the nightly sync around free-tier limits.
Backboard: Gemma 4 runs through a single Backboard API key, with a request budget and a rules-based fallback.
ElevenLabs: the game's sound effects and ambience were generated with ElevenLabs and shipped as static assets.
Gemma: Gemma 4 names the plants and writes the journal, and the whole app works without it.
GitHub Copilot: Copilot was my pair programmer while building Moss Garden, and github workflows are created by the Github Copilot too

What's Next?

I'd love to keep improving Moss Garden without losing the principle that made me build it in the first place.

The most important thing is to keep the experience dependable: preserve the garden, make synchronization predictable, keep the game rules testable, and ensure the optional AI remains optional.

There is room to expand the garden's visual language, improve the onboarding experience, and make the local-model path more practical. But I don't want to add features simply because a productivity app is expected to have them.

Every addition should answer one question: does this make the garden more welcoming, more useful or more trustworthy?

If the answer is no, it probably doesn't belong.

Come Wander Around

If you try Moss Garden, I'd love to hear what the experience feels like after a few days, especially if you take a break and return to it later.

Does a garden that remembers your progress feel different from a graph that counts your days? Which parts would make you want to come back, and which parts feel unnecessary?

You can explore the demo without signing in, inspect the implementation, and follow the rules in the repository:

Explore the live demo
Read the source code on GitHub

The project is open source, and feedback, bug reports and thoughtful contributions are welcome.

I'd like Moss Garden to be the kind of tool that makes you happy to return, not one that makes you afraid to leave.

Built solo, slowly and steadily, by Aditya Kumar.

What If Your Local Kirana Store Could Predict Tomorrow's Demand? Meet DukaanDost

Aditya Kumar — Wed, 14 Oct 2026 11:52:24 +0000

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

⭐ If this is useful to a shop near you, star the repo: DukaanDost. It helps the next counter find it.

Who I built it for

Sharma Kirana is the shop next door. The owner already had a billing export, and he still ordered by feel.

A quiet week might mean nobody wants the item. It might also mean the shelf was empty. A festival week can look like a spike that will not come back. Packs arrive in fixed sizes, and a bad buy ties up cash a small counter does not have.

I built DukaanDost for that counter. Kam andaaza. Sahi stock. Behtar dukaan. Less guessing. The right stock. A better shop.

He used it. He read the forecast against his sales and the festivals coming up, and he restocked candles and oils, because the prediction put those items in demand.

Other people building for the same counter ran into the same facts. A forecast that looks fine for a product family falls apart at the SKU, which is the only level a shopkeeper buys at (Why Your Demand Forecast Is Wrong at the SKU Level). A kirana that runs out of milk on Sunday is a stockout, not a demand of zero (My friend's kirana store runs out of milk every Sunday). And TabPFN plus Gemma can sit behind a small shop's own history, as in SECONDO, without the screen pretending a fallback was the model.

The problem it solves for him

His bills already knew what sold. They did not tell him what to buy next, in which pack size, or whether a quiet stretch was a stockout. DukaanDost turns that file into a quantity he can check before the next purchase.

What it does

DukaanDost takes a billing CSV and writes item-level demand, a reorder quantity, and a short explanation.

Forecasts are built per product from lagged sales, rolling pace, and the calendar.
Restock is lead-time demand plus safety stock, rounded to pack size.
A stockout is not treated as proof that nobody wants the item.
You can compare weeks. The app does not invent a festival uplift.
Bad dates, blank products, and duplicate files are listed with row numbers.
Explanations are English or Hinglish. If Gemma does not answer, a template says so.
If TabPFN cannot run, the screen names the baseline. It does not call that baseline TabPFN.

Forecasts are estimates, not a promise of tomorrow's sales. The public sample file uses the same shop name and is marked fictional, so a visitor does not confuse that demo with his bills. The candle and oil restock came from his own sales.

What's in it

Area	What you can do
Sample	Open a labelled sample kirana that stays separate from your own shop
Import	Preview a CSV, map columns, and see row errors before anything is saved
Inventory	Update stock, with an audit row for receipts and adjustments
Forecast	One series per product, or a clear note when the history is too thin
Restock	Reorder point, pack size, slow-moving flag, stockout flag
Words	English or Hinglish. Gemma through the Google endpoint when a key is set and the words still match the numbers
Export	Inventory, forecasts, recommendations, import quality, and evaluation as CSV
Privacy	SQLite when no Supabase key is set. The hosted demo stores shop rows in Supabase and says so

Demo

The public site is https://dukaandost-web.onrender.com. The API is https://dukaandost-api.onrender.com.

A free Render service sleeps. The shop page can sit on a loading block until /health answers. Use the sample shop on that demo. Anything you import there is stored in the hosted Supabase project, not on your computer.

DukaanDost

Kam andaaza. Sahi stock. Behtar dukaan.

DukaanDost turns a small shop's billing CSV into stock advice the owner can check. TabPFN forecasts demand through the Prior Labs API when TABPFN_API_KEY is set. Gemma explains the numbers in plain language when LLM_API_KEY is set and the reply still matches the math. If either one is absent, the shop still gets a named baseline and a template that says so.

It is built for one real counter: Sharma Kirana, next door. He restocked candles and oils from the forecast.

Built by Aditya Kumar (@ADITYA-KUMAR-2358) for the DEV Hacktoberfest challenge, Side Hustle.

Code

https://github.com/ADITYA-KUMAR-2358/Dukaan-Dost

The application code is MIT. TabPFN is called through the Prior Labs API. This repository does not ship model weights.

How I Built It

TabPFN reads the billing table when an API key is set. Gemma writes the explanation when its own key is set. Neither one is allowed to wear the other's name. On the hosted check I ran, the forecast path used a named baseline, and the explanation came back as the template. The status screen can say Gemma is configured while a particular reply is still the template. The screen has to say which one it was.

TabPFN comes in through tabpfn-client. An empty TABPFN_API_KEY stays on a named baseline: seasonal naive, Croston, or a moving average. There is no weight download in this deploy.

Gemma is optional, through Google's OpenAI-compatible endpoint (gemma-4-26b-a4b-it by default). Leave LLM_API_KEY empty and the template is used. The reply is kept only when it still matches the calculated numbers.

The hosted shop data goes through the Supabase Data API. SUPABASE_DB_URL can stay empty. The backend credential is SUPABASE_SECRET_KEY. The publishable key is public, and the schema does not grant it access to the shop tables. Run backend/app/db/supabase_schema.sql in the Supabase SQL editor after the secret key is in the environment. With both the URL and the key empty, the API uses a local SQLite file.

Architecture

+--------------------------------------+
| BROWSER                              |
| React 19, Vite, TypeScript           |
| Tailwind v4, GSAP                    |
| Render static site                   |
+--------------------------------------+
                 |
                 |  CSV, then JSON
                 v
+--------------------------------------+
| FastAPI on Render                    |
| pandas                               |
| Supabase Data API, or SQLite         |
+--------------------------------------+
        |                    |
        v                    v
   Prior Labs           Gemma via Google
   TabPFN API           or an English /
   or a named           Hinglish template
   baseline

Layer	Choice	Why
Frontend	React 19, Vite, TypeScript, Tailwind v4, GSAP	A shop page that stays readable, with a few deliberate motions
Backend	FastAPI, pandas, Supabase Data API or SQLite	Hosted shop rows in Supabase. A local file when those keys are empty
Forecast	TabPFN through the Prior Labs API, then a named baseline	Tabular history is what a billing CSV already is
Words	Gemma 4 through the Google endpoint	Optional. Empty API key keeps the template
Honesty	Model id stored with the run	A fallback is never labelled TabPFN

From a billing file to an order

 Owner exports a billing CSV
        |
        v
 Preview, map columns, list bad rows
        |
        v
 Features: lags, rolling pace, calendar
        |
        v
 TabPFN API ---- no key or the call fails ----> seasonal naive,
        |                                         Croston, or
        |                                         moving average
        v
 Reorder quantity, rounded to pack size
        |
        v
 Gemma explains the numbers
        |   no key, or the reply drifts
        v
 English or Hinglish template, and it says so

Things I had to get right

Naming the model that actually ran. If TabPFN cannot run, the baseline keeps its own name.
Keeping his shop separate from the sample. The demo file is fictional on purpose.
Not inventing a festival uplift. He can compare weeks. The app does not add a festival percentage he cannot see.
Not treating a stockout as "nobody wants this."
Checking Gemma. If the sentence does not match the calculated numbers, the template is what he reads.
Keeping the publishable Supabase key out of the write path. That key is meant to be public.

What was hard

The Render install. realtime, which ships with the Supabase client, needs Pydantic 2.11.7 or newer. Pydantic 2.14 needs typing-extensions 4.16, and tabpfn-client 0.2.7 only allows 4.15. The pins that install together are pydantic==2.13.5 and typing-extensions==4.15.0.
A public key that could write every shop table. The first schema granted that to anon. The backend now looks for SUPABASE_SECRET_KEY, and the schema file revokes the public grants. The SQL still has to be run in the Supabase editor after the secret key is saved.
Thin history. Some items do not have enough days for a fit. Those rows need a clear note, not a confident number.
A quiet Gemma. With no API key, or when a call does not come back clean, the template has to be good enough to order from, and it has to admit Gemma was not used.
A sleeping host. The static site can be up while the free API is still waking. The shop page waits on /health instead of showing an empty shop as if the data were gone.

What I'd do next

A printed order list he can take to the wholesaler, and Hindi on the rest of the screen so the whole shop, not only the explanation, can be read in the language he uses at the counter.

Why Does Open Innovation Matter?

Sharma Kirana's bills are a private record. What sold last Tuesday should not have to leave the shop before he can decide what to buy.

Control. With no Supabase key, the forecast and the SQLite file stay on the shop computer. On the hosted demo, shop rows live in Supabase. Gemma is off until LLM_API_KEY is set, and then only the calculated facts are sent, not the raw CSV. TabPFN, when its key is set, sends the feature table to Prior Labs.
Swappability. TabPFN can be turned off. Gemma's model name is a setting. The baseline and the template still answer.
Cost. An empty key spends nothing. Gemma uses the limits in .env (LLM_MAX_RPM, LLM_MAX_PER_DAY, SUBMIT_LIMIT).
Tunability. The rule that mattered most was faithfulness: show the number you calculated, and name the model that produced it.

A closed forecast that fails and still comes back wearing the vendor's name is worse than a baseline with its own name. The screen has to say which one ran.

My Agent Session

DukaanDost: Supabase on Render, and the Pydantic pin that installs

You

The API does not stay up. Supabase is reachable, and the shop tables are still missing until the schema SQL is run. That schema lets the publishable key read and write every shop table. A secret key should be the backend credential. SUPABASE_DB_URL and BACKEND_URL are empty. The local shop in SQLite is not in Supabase.

Agent

The ten shop tables already answered on the Data API, and the local API health check returned ok. SUPABASE_DB_URL stays empty because the app uses the Data API, not a Postgres password. BACKEND_URL stays empty because the guessed Render hosts returned no-server, and a keep-alive ping against a dead host would fail every 10 minutes. SUPABASE_SECRET_KEY was added as a server-only setting. The schema SQL now drops the public api_access policy and revokes anon and authenticated grants. That SQL could not be applied from here: the Supabase SQL editor requires a sign-in. Until the secret key is pasted and that SQL is run, the API still falls back to the publishable key. The SQLite file had a sample shop and an empty local shop named My shop. My shop was copied. The sample rows were already in Supabase, so the duplicate sample was removed. The shop already open in the app stayed the active shop.

▸ copy_sqlite_shop Read the local SQLite file and insert missing shop rows through the Data API.

Input

Read the local SQLite file and insert missing shop rows through the Data API.

Output

My shop copied. Duplicate sample removed. Active shop left unchanged.

You

Commit and push the project.

Agent

The CI workflow went up first, then the app, frontend, sample CSV, and Render blueprint. .env and the local database were not committed. GitHub renamed the pushed branch to main.

You

The Render build failed. realtime 2.7.0 needs pydantic>=2.11.7, and requirements.txt pinned pydantic==2.10.4.

Agent

Pydantic 2.14.1 satisfies realtime, but it needs typing-extensions>=4.16.0, and tabpfn-client 0.2.7 only allows typing-extensions<=4.15.0. The pins that install together are pydantic==2.13.5 and typing-extensions==4.15.0. A dry-run resolved, and the 16 backend tests passed. That commit was fast-forwarded onto main.

▸ pip_dry_run pip install --dry-run -r backend/requirements.txt

Input

pip install --dry-run -r backend/requirements.txt

Output

Would install pydantic 2.13.5, pydantic-core 2.46.5, and typing-extensions 4.15.0. Resolution succeeded.

You

The static site is built, but nothing is being shown at the public web URL.

Agent

The home page was serving the built marketing page, with the stylesheet and script loading. The shop view at /app showed loading blocks until the API answered. /health on the API returned 200, and /api/status returned the active shop with an access-control-allow-origin for the static site. After that response, the overview heading was the shop name. A free Render instance can sit on those loading blocks while it wakes.

My First User

He is the owner of Sharma Kirana, the shop next door. He used DukaanDost on his own sales. The forecast, read with those sales and the festivals coming up, put candles and oils in demand, and he restocked them.

He has not paid. I built it for his counter. The result so far is stock on the shelf, not a guess from memory.

Prize Categories

Best Use of TabPFN: TabPFN forecasts item-level demand from a billing CSV when TABPFN_API_KEY is set. If the call cannot run, the baseline keeps its own name.
Best Use of Gemma: Gemma explains those numbers in English or Hinglish, and only when the words still match the math. No API key, or a reply that does not match, means the template.

If you know a shop that still orders by feel, start with their last billing file. And if this is useful, please ⭐ star DukaanDost on GitHub. Thank you for reading. ❤️

Walkworth: Walk it. Say it. Keep it. A spoken trek journal on local open-source AI

Aditya Kumar — Sat, 10 Oct 2026 09:53:49 +0000

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

What I Built

Walkworth is a trek journal you speak instead of type. Before a walk you open the app once on Wi-Fi so it caches. On the trail you put the phone in your pocket, and when something is worth keeping you tap once, say it out loud, and tap again. "Langurs on the wall near the gate, three of them, totally unbothered." That's a whole entry. The phone buzzes when it starts and stops listening, so you never have to look at it.

Back home, your laptop turns the voice notes, photos and GPS track into a journal. There's a cover with your route drawn on it, chapters in time order, your own words set large as quotes, and photos pinned to where you took them. You can print it, publish it, or paste it into a DEV post like this one.

I wanted the screen to be the shortest part of the day. On the trail the whole interface is one button. It's for people who walk a lot and can't remember any of it by Monday, and for anyone who'd like a record of a walk without spending the walk on their phone.

Demo and live link

walkworth.onrender.com

Code

ADITYA-KUMAR-2358 / WalkWorth

Walkworth

Walk it. Say it. Keep it.

A spoken trek journal. You talk while you walk and your phone stays in your pocket. Each voice note and photo uploads as you go (or waits on the phone until you're back in range). Then Gemma writes the journal around your own words, and every line it adds cites the notes it came from. A line that cites nothing is dropped before the journal is made.

How it works

Start a walk. One big button: tap, talk, tap. The phone buzzes when it listens, and each note gets a GPS fix.
It uploads as you go. Notes and photos are kept in the browser until the server has them, so a dropped signal or a closed tab loses nothing.
Make the journal. A Temporal workflow transcribes (ElevenLabs Scribe), lines notes up with the GPX track, picks out what you saw, captions photos…

View on GitHub

How I Built It

The phone only records. Everything smart happens on the laptop afterwards, and I made that split on purpose. Fort trails around Pune often have no signal, and I didn't want a trek journal that needs a network or burns battery running models in my pocket.

On the phone. A PWA built with Vite and TypeScript. A service worker handles offline caching, MediaRecorder does the audio, each note grabs one GPS fix, and IndexedDB stores it all. For the continuous route I use OpenTracks, an open-source Android tracker, because browsers pause GPS when the screen locks. The PWA also counts how long the screen was on, which is where the screen-time number comes from.

On the laptop.

whisper.cpp (the small model) transcribes every clip. It copes with Hindi, Marathi and English in the same sentence, which is how I talk anyway.
Gemma 3 through Ollama does the rest: it pulls structured observations out of each transcript, captions the photos, and writes the short connecting lines. I run gemma3:4b by default and gemma3:12b when the machine allows. The model name is one line in walkworth.config.toml.
Temporal runs the pipeline as a single workflow: import, transcribe, align, extract, caption, compose. Each step is a durable activity with retries.
FastAPI and SQLite hold the data. No cloud database.
Render hosts one thing, the finished journal as a static site.

The one rule I'm strict about. The journal can't lie. Every sentence the model writes has to carry the ids of the notes it came from, and a sentence with no source gets dropped before it renders. Your quotes always appear word for word. So the model can arrange and trim, but it can't invent a sighting you didn't make. I'd rather lose a nice sentence than print a fake langur.

What went wrong. I started OpenTracks forty minutes late. I was already past the first bend at Atkarwadi, chai in one hand, when I remembered. So the first 2 km of the climb has no track at all. The app rebuilt it from the GPS fixes on my voice notes, and the route on the cover has one straight line where the switchbacks should be. I left it.

Whisper struggled with the fort. It heard "Tanaji Kada" as "tanaji cada" and "Kalyan Darwaja" as "kalyan the wajah". Everything else came out clean, so I didn't notice until I read the landmark chips and 5 of the 9 were gibberish. I added a short glossary of 12 fort names, and now it fixes them before anything else sees the transcript.

The fog was the worst. Around 7:50 at the top I said four notes in a row into a wind so loud that two of them are just noise, with my voice buried somewhere underneath. The journal skips them. The gap sits between the gate and the bhaji stall. I could've faked a line to fill it, but every sentence in this thing is supposed to be something I actually said. So it stays empty.

Why Does Open Innovation Matter?

Here's what going open actually bought me, from things that happened while I built this.

The fort has no signal. A closed API would stop working at the base of the climb. With Whisper and Gemma on my laptop the whole pipeline runs with Wi-Fi off.

The recordings are my voice and several hours of my location history. I didn't want either on a server I don't control. With local models nothing leaves the laptop. When I publish, only the finished journal goes online, and there's a switch that hides the first and last 300 metres of the route so nobody can tell where I started.

And I can swap models by changing one line in the config. When Whisper mangled the fort names, the fix was a small glossary file I could edit myself. You can only make that kind of fix when you own the stack. It costs nothing per trek, too.

Prize Categories

Best Use of ElevenLabs: I used ElevenLabs to narrate the voiceover of the demo video and also for text to speech and speech to text generations ElevenLabs is being used.
Best Use of Gemma: Gemma 3 runs locally through Ollama for extraction, captions and journal writing.
Best Use of Temporal: the whole post-trek pipeline is one workflow.
Best Use of Render: the finished journal is deployed as a static site from a render.yaml

Please Give this a read

Aditya Kumar — Sat, 03 Oct 2026 15:17:23 +0000

Hacktoberfest: Maintainer Spotlight

Aditya Kumar

Oct 3

Salt & Story: My Maasi's Recipes, Saved in Her Own Voice

#devchallenge #weekendchallenge #hf26challenge #hacktoberfest

9 min read

Salt & Story: My Maasi's Recipes, Saved in Her Own Voice

Aditya Kumar — Sat, 03 Oct 2026 15:16:50 +0000

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

⭐ If this story means something to you, please star the repo: github.com/ADITYA-KUMAR-2358/salt-and-story. It helps more families find it.

What I Built

Who I built it for

My Maasi (my mom's sister, my aunt) has cancer. A few weeks ago we learned she probably has two to three years left.

She makes the best food I know. Not fancy food: comforting, tasty, the kind you remember for the rest of your life.

A few days back I saw her writing in her diary. When I asked, she told me it was her famous chili and lemon pickle recipe. She had written a few others too, each with a lovely message and the name of the person it was for. My favourite thing she cooks is her Dahi Wada, and guess what: there it was, a recipe addressed to me.

She had spent hours writing those pages by hand. So I thought: what if she could just talk, the way she does in the kitchen, and her recipe came out exactly in her words?

That became Salt & Story. Maasi has now recorded those recipes with her voice, and they are live, written the way she said them. I also added a way to turn them into a personalised book, and a lot more, because every recipe has a story.

The problem it solves for her

Writing recipes by hand is slow and tiring, and the way Maasi really cooks ("a pinch of this, cook it till it looks right") never fits neatly on a page anyway. Salt & Story lets her simply speak, and it keeps her exact words instead of flattening them into a generic recipe. For our family, it means her food and her voice stay with us.

What it does

Salt & Story is a web app that turns spoken recipes into a printable family cookbook.

You record a voice memo in the browser (or upload one, or paste the words), and Salt & Story:

transcribes it,
structures it into ingredients, steps and tips,
turns vague measures like "a fistful" into rough quantities while keeping the original phrase right next to them,
keeps one memorable line, verbatim, as a pull-quote (checked against the transcript in code),
never invents an ingredient, amount or step that wasn't said,
exports everything as a designed A5 PDF cookbook.

The goal was never a recipe database. It was a book that sounds like Maasi.

What's in it

Area	What you can do
Capture	Record in the browser with a live level meter, upload a memo (mp3, m4a, wav, webm, ogg), paste a transcript, or write a recipe by hand
Recipe	Read it with an ingredient checklist and tappable steps, edit everything (with an unsaved-changes guard), add a photo, keep the original transcript one tap away
Cook mode	One step at a time in large type, the screen kept awake, arrow keys or big buttons
Listen	ElevenLabs narration of the whole recipe, cached so it is paid for once
Book	Pick and order recipes, a live cover preview, a dedication, an editable "Recipes told by" line, and an A5 PDF with contents and page numbers
Organise	Search, favourites, delete with confirmation, backup and restore as JSON
Accounts	Sign in with Google; each family's recipes are private to their account; delete your account and everything in it
Start fast	Six American and European family classics with openly licensed photos, added in one tap
Comfort	Light and dark mode, 17px base text, 44px tap targets, keyboard and screen reader friendly, reduced-motion support

Demo

Live app: https://salt-and-story-web.onrender.com/

Code

ADITYA-KUMAR-2358 / salt-and-story

Salt & Story turns voice memos of a relative cooking into clean, printable recipes, while keeping the speaker's own words beside them. Record or upload a memo, an open-weight model (Gemma 4) writes it up, and you export a cookbook PDF that looks like a gift. It is built for one real family: Because Every Recipe Has A Story

Salt & Story

Because Every Recipe Has A Story

Salt & Story turns voice memos of a relative cooking into clean, printable recipes, while keeping the speaker's own words beside them. Record or upload a memo, an open-weight model (Gemma 4) writes it up, and you export a cookbook PDF that looks like a gift.

It is built for one real family: the person who tells recipes out loud and has never written them down, and the grandchild who wants to keep them.

Built by Aditya Kumar (@ADITYA-KUMAR-2358) for the DEV Hacktoberfest Weekend Challenge, "Build for a Friend".

Agents and contributors: start with docs/ (PRD, Architecture, Rules, Design, Tasks, Memory).

What it does

Capture: record in the browser (live level meter), upload a memo, paste a transcript, or write a recipe by hand.
Write it up: ElevenLabs…

View on GitHub

⭐ A star on the repo would genuinely make my day.

How I Built It

Open-source AI at the core: Gemma 4 (gemma-4-26b-a4b-it, Google's open-weight model) structures every recipe. I call it through the Gemini API's OpenAI-compatible endpoint on the free tier, so the same code also runs against local Ollama (for example gemma3:4b) by changing three environment variables. The model turns a rambling transcript into structured JSON, and it is the heart of Salt & Story.

Architecture

+--------------------------------------+
| BROWSER                              |
| React 19, Vite, TypeScript 7         |
| Tailwind v4, GSAP                    |
+--------------------------------------+
    |             |              |
    | app files   | JSON +       | Sign in
    |             | Bearer       | with Google
    v             v              v
+--------+  +-------------+  +----------+
| Static |  | FastAPI     |  | Google   |
| site   |  | Python 3.14 |  | Identity |
+--------+  +-------------+  +----------+
                   |
                   +--> SQLite: accounts, recipes
                   +--> Files: photos, audio
                   +--> ElevenLabs: STT + TTS
                   +--> Gemma 4: Gemini API
                   |             or Ollama
                   +--> WeasyPrint: HTML -> PDF

  Hosted on Render (or docker compose locally)

Layer	Choice	Why
Frontend	React 19, Vite, TypeScript 7, Tailwind v4, GSAP	Fast to build, strict types, a few deliberate animations
Backend	FastAPI, Pydantic v2, SQLModel on Python 3.14	Typed models end to end; background tasks for slow AI work
AI writer	Gemma 4 26B (A4B) via an OpenAI-compatible API	Open weights, swappable host, free tier
Speech	ElevenLabs Scribe (speech-to-text) and multilingual TTS	Handles messy kitchen audio; natural narration
PDF	WeasyPrint with Jinja2 templates	Real print CSS: page counters, running headers, leaders
Accounts	Google Identity Services + signed sessions	No passwords to store
Hosting	Render Blueprint: Docker web service + static site	One `render.yaml` describes both

From a voice memo to a recipe

 Cook records or uploads a voice memo
        |
        v
 ElevenLabs Scribe ----> transcript
        |
        v
 Gemma 4 <---- rules: never invent,
        |             keep their words
        v
 recipe as JSON
        |
        v
 Pydantic check --bad JSON--> retry,
        |                     error fed back
        v
 Is the quote really in the transcript?
        |   no --> use closest real sentence
        v
 Ready to read, cook, edit and print

The status moves uploaded → transcribing → structuring → ready (or failed, always with a reason and a next step). If the server restarts mid-memo, it marks that memo as interrupted instead of leaving a spinner forever.

Things I had to get right

Not inventing things. The prompt forbids adding ingredients or steps that weren't said, the JSON is validated with Pydantic, and bad output is retried with the validation error fed back. For Maasi's recipes this mattered more than anything.
Keeping her voice. The pull-quote must be an exact substring of the transcript. The code checks this and falls back to the closest real sentence if the model paraphrases.
Swappable models. The model endpoint is three environment variables, so the same code runs against local Ollama or a hosted open-weight model.
A book that looks like a gift. Each recipe is a two-page spread: photo, title, story and their words on the left; ingredients, method and tips on the right. Steps never split across pages, headings never strand at the bottom, and continuation pages carry the recipe name in a running header. I checked it by rendering real books and looking at every page.
A free API key that strangers can't drain. See the next section.

Protecting a free API key

A public demo on free tiers needs guardrails, so every request passes through several layers:

 Sign in with Google
   |-- throwaway email domain?  --> refused
   |   (about 9,200 blocked)
   |-- 2+ new accounts from this
   |   network today?           --> refused
   v
 Ask for a recipe
   |-- account used its 5 today? --> try tomorrow
   |-- network used its 10?      --> refused
   |-- same transcript before?   --> reused, free
   v
 Throttle + queue (one call at a time)
   |-- 429 or 5xx --> wait, retry, then explain
   v
 Gemma 4 writes the recipe

Guard	Default	Purpose
Recipes (or narrations) per account per day	5	Fair share of the free quota
New accounts per network per day	2	Stops one device making many accounts
AI requests per network per day	10	Stops one device spending many accounts' quota
Throwaway email domains refused	about 9,200	No disposable sign-ups
Requests per account per 10 minutes	8	Stops bursts
Model calls per minute / per day (whole server)	10 / 300	Last line of defence for the key
Identical transcripts	reused	"Try a sample" costs nothing the second time

Only real AI calls count against an account's 5: writing by hand, editing, photos, classics and books are free. IP addresses are stored only as salted hashes, and the visitor's IP is read from Cloudflare's True-Client-IP header on Render, never from a header the client can fake.

Numbers

What	Result
Time to write one recipe, Gemma 4 default reasoning	80 to 190 seconds
Same, with minimal thinking (`thinking_level: minimal`)	12 to 44 seconds in most runs (one slow free-tier run took about 2 minutes)
Backend tests	83, all mocked (no quota used)
Backend branch coverage	92% (CI requires at least 90%)
Browser checks against the Docker build	123: every page, every link, the book PDF, a real Gemma recipe
Responsive audit	14 pages at 5 widths (320 to 768px) plus 6 sizes up to 1920px: no text overflow
A six-recipe book	19 A5 pages including cover, contents and closing page
Python versions tested	3.13 and 3.14

Quality checks on every pull request

 Pull request
   |
   +--> Lint + format (ruff, Oxlint) -----+
   |                                      |
   +--> Security (CodeQL, Gitleaks,       |
   |    pip-audit, npm audit) ------------+
   |                                      |
   +--> Tests (Py 3.13 + 3.14,            |
   |    coverage >= 90%) ---+             |
   |                        |             |
   +--> Type check + build -+             |
                            |             |
                            v             |
              Docker build + 123          |
              browser checks -------------+
                                          |
                                          v
                              All checks passed
                                          |
                                          v
                                   Ready to merge

Dependabot keeps Python, npm, Docker images and GitHub Actions up to date, and every update goes through the same checks.

What was hard

Speed. Gemma 4 reasons before it answers, and my first recipes took up to three minutes. Passing a minimal thinking level brought that down to well under a minute with the same quality.
Reasoning text in the output. Gemma 4 prefixes its answer with a <thought> block, which broke JSON parsing until I stripped it.
Free-tier limits. 429s and the occasional 500 from the provider needed polite retries, a one-at-a-time queue and clear "try again in a minute" messages instead of crashes.
The PDF engine everywhere. WeasyPrint needs native libraries (Pango): easy in Docker and on Render, painful on Windows until I scripted a private install.
The real visitor IP. Behind Render's proxy, the usual X-Forwarded-For header can be faked by the client, so the per-network limits read Cloudflare's True-Client-IP instead.
Tooling on the newest versions. TypeScript 7 is so new that typescript-eslint doesn't support it yet, so I lint with Oxlint instead.

What I'd do next

Hindi and Hinglish support (with a Devanagari PDF font), so Maasi's recipes can be printed in the language she actually speaks; shared family libraries so several relatives can add to one book; playback of the original voice memo, so we can always hear her say it; and a printed hardcover option.

Why Does Open Innovation Matter?

Salt & Story handles something deeply personal: a family member's voice and memories.

Control. With an open-weight model, the structuring step can run on my own machine or server. In the hosted demo, audio goes to ElevenLabs for transcription and transcripts go to Google's Gemini API, which runs Gemma; switching LLM_BASE_URL to local Ollama keeps transcripts on my own computer.
Swappability. Because the model sits behind a standard endpoint, I can change models without rewriting the app.
Cost. It's free to run, on the free tier or locally, which matters when the "user" is a family member and not a customer.
Tunability. I could shape the prompt and behaviour to protect what mattered most: faithfulness to what was actually said.

With a closed model, Maasi's words would only ever be processed wherever one company decided. With open weights, they can stay with our family.

Prize Categories

Best Use of Gemma: Gemma 4 structures every recipe, with its output validated and its quotes checked against the transcript.
Best Use of Render: Salt & Story is deployed on Render from a Blueprint: a Docker web service for the API and a static site for the app.
Best Use of ElevenLabs: speech-to-text turns voice memos into transcripts, and text-to-speech reads recipes aloud.

Somewhere in that app is a Dahi Wada recipe with my name on it, in Maasi's own words. That's the whole reason it exists.

If you have someone whose recipes live only in their head, record them while you can. Try it: https://salt-and-story-web.onrender.com/

And if this story touched you, please ⭐ star Salt & Story on GitHub. Thank you for reading. ❤️