Pincode Garden: what to plant this week, from your pincode

Ishaan — Wed, 07 Oct 2026 15:32:35 +0000

Pincode Garden: what to plant this week, from your pincode

Live demo: https://pincode-garden.onrender.com/
Repo: https://github.com/ishaan-jindal/pincode-garden (MIT)

The problem

I have killed every plant I ever touched. The advice online is always "zone 9b, last frost March" — useless when your pincode is 110016 and your garden is a balcony with three hours of sun.

So for Hacktoberfest Week 1 (Touch Grass) I built the smallest thing that answers one question: given my pincode, my minutes per week, my sun, and my experience, what should I sow this week?

You enter four fields, you get up to three crops with a sow-by date, one short tip, and the frost window it was grounded in. Then you are supposed to close the laptop and go sow something. The screen part takes twenty seconds. That is the point.

What it does

Input: pincode, minutes per week, sun (full / partial / shade), experience (new / some / green).

Output: three ranked crops, each with why it fits, a sow-by date, and a fit score — plus one tip line, the last/first frost for your prefix, weeks left in the window, and two flags: smart advice on/off, yield check on/off.

Example — 110016, 30 min, partial sun, new gardener — returns coriander, lettuce, marigold with a tip like "Sow coriander 3in apart; keep moist, harvest in about 35 days." Completing a planting logs a streak in a flat file. No accounts, no database, no keys.

The read-aloud button reads the tip plus the top pick, so you can listen once and put the phone away.

How open-source AI is at the core

Two open pieces do the actual work, both with the same honest pattern: try the real model, fall back to a deterministic stub, label which path ran.

Gemma 4 via Ollama writes the tip. The prompt is grounded in the top-ranked crops only, strict JSON, one line. Model and host come from GEMMA_MODEL (default gemma4:e2b) and OLLAMA_HOST. No cloud calls, no keys, no per-token bill.
TabPFN V2 (CPU) ranks the candidates. Features are tabular and small: sun match, frost-window fit, harvest fit, experience, month. The training table (data/history.csv, 32 rows) is reference outcomes encoded from planting guides, not fake telemetry. Fit happens once and is cached; any failure falls back to a weighted stdlib scorer over the same features.

Why open mattered here: the whole brain runs on-device or not at all. Nothing about your pincode or garden leaves your network. The stub path means the demo works with Wi-Fi off — Gemma makes tips warmer when home, TabPFN sharpens ranking when torch is around. On Render free the deployed demo runs the deterministic fallback by design, and the UI says so. Locally, uv sync --extra tabpfn plus ollama run gemma4:e2b enables both real paths with zero code changes.

Frost dates without an API

data/frost.csv is ten rows: pincode prefix to first/last frost (MM-DD), plus a fallback row for unknown prefixes. North prefixes get a real window; southern ones get year-round. All math is stdlib dates. No fetch, no keys, no outage mode.

Crops live in data/crops.csv (14 rows). Candidates are filtered by sun, difficulty, time budget (under 30 min/week keeps easy herbs/greens only), and whether the sow-by date is still inside the window. Unknown pincodes never crash; they get the fallback window.

Stack and shape

FastAPI plus stdlib. No ORM, no auth, no image uploads, no weather API, no geolocation. Streaks are a JSON file. Frontend is one 74-line HTML file, system font, no framework, speech synthesis for read-aloud. Tests are five offline pytest cases with stubs forced. Docker plus render.yaml on the free tier.

What I would add with more time

A second frost source with provenance per row, and a photo log for the streak instead of a counter. Neither fits a four-day window without adding a database I would have to maintain.

BOSS vs YOU: I Built a Boss Fight for My Bored Friend — and an Open LLM Plays the Boss

Ishaan — Sun, 04 Oct 2026 16:15:58 +0000

BOSS vs YOU: I Built a Boss Fight for My Bored Friend — and an Open LLM Plays the Boss

My friend is bored by every game I show him. Too easy, too grindy, too predictable — the boss does the same three moves, so why keep playing? Fair. So for the Hacktoberfest Weekend Challenge (Build for a Friend), I built him a boss fight where the boss is played by an open-weights LLM that studies how he plays and adapts. Same three moves? Not anymore.

Play it: https://boss-vs-you.onrender.com (free tier — give it ~50s to wake up)
Code: https://github.com/ishaan-jindal/boss-vs-you (MIT)
Challenge: https://dev.to/challenges/hacktoberfest-weekend-2026-10-01

What it is

BOSS vs YOU is a real-time pixel-dungeon boss battler in the browser. You descend room by room through a cramped gothic dungeon. Each room: kill the minions, crack the boss phase, draft a level-up card, go deeper. The twist: one transforming boss (four forms), driven by a model brain, with a memory.

Roughly every 8 seconds the server sends the full fight state — HP, positions, your habit profile, the room — to the model, which returns tactics (pressure / bait / bombs weights), whether to transform, what to open with, and even a taunt. A rules-based stub stands behind every call: model fails, times out, or returns garbage, and the deterministic floor takes over. The game never 500s, and it plays fully offline with no keys at all.

And the part built to hook him: it learns whoever plays. The server distills the last 60 fights — turtle ratio, dash spam, potion timing, preferred range, causes of death — into a habit profile the boss prompt reads. Camp in the corner and the boss starts baiting. Dash everywhere and it starts punishing.

His honest review: "addictive... but a little easy" — then, a few descents later, the dungeon thrashed him. Boredom: cured.

How it's built

flowchart LR
    UI[Pixel Canvas client] --> API[FastAPI server]
    API --> Brain[brain: contract + stub]
    Brain --> Habits[habits: 60-fight profile]
    Brain --> Gemma[(Gemma 4 primary)]
    Gemma -.failover.-> DI[(DeepInfra Gemma)]
    Brain -.fallback.-> Brain

The stack is deliberately boring: FastAPI + uvicorn, raw httpx to the model APIs (no SDK), vanilla JS + Canvas 2D (we deleted a 1.3MB vendored Three.js mid-weekend for a 210-line pixel renderer), procedural sprites and Web Audio so there are zero asset files. The server is fully stateless — persistence is browser localStorage. Python is the tuning ground truth; the JS client mirrors four formulas, pinned by a parity test (93 tests, all green).

Why open matters

This game only works because the model is open:

Swappable by design. Primary and failover are both Gemma 4 served two different ways (Google REST, DeepInfra OpenAI-compatible). Point the brain at any weights-compatible endpoint — including a locally-run Gemma — with a two-constant change. Try that with a closed API.
Free to run, online or off. No keys, no internet? The stub brain plays a real game. The whole weekend cost $0: open weights, free-tier Render, MIT everything.
Inspectable opponent. Anyone can read the exact prompt the boss sees and the exact counters it keeps on them. A black-box boss that adapts is marketing; an open one is a rivalry.

Tracks

Best Use of Gemma: Gemma 4 is the boss's brain — tactics, transforms, taunts — with thinking capped to MINIMAL after measuring full reasoning at 20-40s per tick.
Best Use of Render: Docker deploy, health checks, secrets in the dashboard. (Shipped a real Dockerfile bug along the way: installing before src/ existed silently produced an empty editable install — reorder plus a non-editable build fixed it.)

Built this weekend for one bored friend. If he finally stops complaining, I'll consider it a win bigger than any prize.

DEV Community: Ishaan

Pincode Garden: what to plant this week, from your pincode