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

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:

1. Connect GitHub. The player signs in and selects the repositories they want Moss Garden to consider.
2. Synchronize activity. A scheduled backend job fetches eligible commit activity, so the player doesn't have to manually record anything.
3. Apply the rules. The Python game engine calculates XP, levels, vitality, plant growth and badges from the activity and the game's rules.
4. Persist the result. The backend stores the garden's state so the experience can continue across sessions.
5. 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.

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:

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:

1. 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.
2. 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.
3. 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.