DEV Community: Tanay

A lazy day is just packet loss. So my step goal backs off like TCP.

Tanay — Sun, 25 Oct 2026 21:08:22 +0000

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

Before writing this post I exported my own last 90 days of steps. I reached 10,000 on none of them. Not
one day, in a stretch where I logged 43 workouts in Hevy. Every fitness app I have used still opens with the
same number, and a goal you never reach is not a goal. It is a reason to stop opening the app.

I work on message queues for a living, so I spend my days around a very old idea: when you do not know how
much a network can take, start slow, speed up while things go well, and back off when something is lost.
That is TCP congestion control. Then I remembered that a monster from a game I love has an ability with the
same name, Slow Start: it halves its stats for its first five turns, then never stops.

So I built a fitness game for lazy people where your daily goal works like TCP, an open model keeps it
honest, and a sleepy stone giant wakes up as you walk.

TL;DR

Slow Start sets your step goal like TCP: start small (1,500, or your own level if you import your history), double after a win, climb steadily near your level, halve after a miss, never to zero. TabPFN v2, an open tabular model, caps the goal at a level you reach about 7 days in 10. You never set a goal yourself.

The game: every day a wild creature blocks the path. Its health is your goal, every step you log is a hit, and caught creatures follow your giant, Slumbrock, home. All pixel art is original and drawn in code.

The honest result: on held-out days from 33 real people, a fixed 10,000 steps was met on 34.6% of days. My first controller hit 86.6%, but only by asking for half of what people usually walk. Tuned on a validation window, Slow Start meets 71.1% of days at 74% of a usual day, which ties a plain "your own 30th percentile" rule (69.7%). On my own 90 days: 71.1% against 0% for 10,000.

Open, end to end: TabPFN v2 (Apache 2.0) and Gemma 3 4B run on a server I control. Nothing goes to a closed AI service. Web, Android APK and source are all public.

What I Built

Slow Start is a web game and an Android app with three ideas inside:

A goal you can win, that moves with you. The step controller is TCP's congestion window. A second limit, TabPFN's prediction of tomorrow, plays the receiver window. Your goal is the lower of the two.
A reason to come back. Slumbrock, a stone giant asleep for three hundred years, wakes through four stages as you earn XP. His Speed and Power both start at half, like his namesake.
No decisions. The goal arrives every morning. If you lift, the next weights and reps arrive too. Walking alone is a full way to play, and a sick day is excused, not punished.

TCP	Slow Start
Congestion window, grown by the sender	Window: the controller's goal
Receiver window, advertised by the receiver	Cap: TabPFN's 30th percentile of tomorrow's steps
Effective window = min(cwnd, rwnd)	Goal = min(window, cap)
Slow start: double per round trip	Double the goal after a won day
Congestion avoidance: add one per round trip	Add 1,500 steps per won day once near your level
Loss: halve, set ssthresh	Missed day: halve the window, remember the level
Cached metrics for a host seen before	Imported history: start from your own level, not 1,500

Demo

Play it: https://slowstart.onrender.com. No account. Scroll the first screen slowly and watch him wake.
Watch the demo: one real person's 40 days from the public dataset, one tap per day. You can see the goal double, get capped, halve after a miss and climb back.
The field guide: every creature, where it lives, how to catch it, and trivia nobody asked for.
Bring your own steps: the export guide walks through Google Fit, a Fitbit or Pixel Watch, Hevy or any CSV, and the import sits right on the game's Today screen. If your file comes out wrong, the app links to a GitHub issue form pre-filled with what it saw, and the case becomes a rule in the cleaner.
Android: the APK is the same build wrapped with Capacitor.

Things to try:

tap Slumbrock and the creature.
Open Why this number? under the goal.
On the Talk tab, tell Slumbrock how your day went.

Code

Tanay3484 / slow-start

Slow Start: TCP-style goals for lazy people, with a pixel-art giant to look after (DEV Hacktoberfest 2026 Week 3)

Slow Start

A fitness game for lazy people. Your daily step goal and your next workout are set the way TCP sets how fast a connection may send: start small, double after each success, grow slowly once you're near your level, and halve after a miss, never to zero. A second limit, TabPFN's prediction of what you'll probably manage tomorrow, stops it asking for too much on a day the history says will be a low one.

You look after Slumbrock, a pixel-art stone giant that wakes up as you keep going. The idea comes from a monster whose ability, also called Slow Start, halves its stats for its first five turns. The creature art and names here are original; nothing is taken from Pokémon or Nintendo.

Built for the DEV Hacktoberfest 2026 Open-Source AI Challenge, Week 3: Slow and Steady.

Live: https://slowstart.onrender.com (the game is at /play…

View on GitHub

backend/ is Python (FastAPI, TabPFN v2, Gemma through Ollama). app/ is TypeScript with no framework: a
small game engine on a 240 × 135 canvas, wrapped as an Android app with Capacitor. Every number in this post
comes from a script in scripts/ and a file in results/. MIT licensed.

How I Built It

Code decides, the models advise

The rule I kept from my earlier weeks: anything that sets a number is plain, tested code.

The controller is a pure function of your history. It replays every day, so the same history always gives the same goal.
TabPFN v2 gets a few features (the last three days, the week's mean and minimum, the fortnight's median, the weekday) and predicts a distribution for tomorrow. The cap is its 30th percentile. It is fitted on your own earlier days plus a small public prior, so a new user is not starting from nothing.
Gemma 3 4B reads a one-line check-in ("leg day was brutal") and answers in Slumbrock's voice. Code, not the model, decides whether the day is excused (a word list with a negation check) and picks the recovery tip from a curated list, so nothing medical is ever made up.

On Render's two CPUs Gemma 4B takes about fifteen seconds to answer. Slumbrock is a sleepy rock, so
the button says he is thinking, and if a reply comes back malformed a template line takes over.

The game engine, all in code

There are no image files for the creatures. scripts/draw_sprites.py draws them from shaded shapes: spheres
and bevelled blocks lit from the top left, a four-tone ramp with a little dithering, outlines in the darkest
tone of each colour. Each creature has idle frames (wings flap, Kettlebub lifts its little bar), a blink and
a hit face. The arena is about 900 lines of TypeScript: an entrance for each new creature, an attack with a
damage number for every step you log, a capture after which the creature follows you, an evolution burst,
and weather and time of day per place. Text is drawn on a second, full-resolution canvas layered on top,
because pixel-font text scaled up from 240 × 135 was an unreadable blur.

The evidence

The data is the public Fitbit Fitness Tracker Data on Kaggle (CC0): daily steps from 35 people in
spring 2016. Of 1,373 person-days, 133 have exactly zero steps. I treat those as "watch not worn", not
scored and not fed to any policy.

Every policy sets each day's goal seeing only the days before it, then the day is revealed. TabPFN is fitted
per calendar day on everyone's earlier days only. A test proves no policy is ever shown the day it is
setting a goal for. Two windows: a validation window (the 14 days before 2016-04-28) for choices, and a
final window (the last 14 days) run once at the end.

Two numbers per policy, because either alone can be gamed:

Goal met: the share of days the person reached the goal.
Asks for: the goal as a share of the person's usual day. A policy that wins by setting tiny goals shows up here.

Final window, 32 people, 350 person-days:

Goal	Goal met	Asks for	Met vs plain 30th percentile (95% CI)
Fixed 10,000	34.6%	148%	−35.1 pts (−48.3 to −21.6)
Your 28-day median	46.3%	101%	−23.4 pts (−28.7 to −18.6)
Your 28-day 30th percentile	69.7%	79%	(baseline)
TabPFN 30th percentile alone	66.6%	84%	−3.1 pts (−9.1 to +2.2)
Slow Start (controller + TabPFN cap)	71.1%	74%	+1.4 pts (−4.8 to +7.4)

The intervals resample people, not days, because one person's days are not independent.

What went wrong, and what I did about it

My first controller won by cheating. With a climb of 250 steps per win, it met 86.6% of goals, which looked great until the guardrail column said it was asking for 50% of a usual day. The TCP sawtooth was the reason: after every halving, climbing back 250 steps a day takes weeks, so the goal sat at half your level most of the time. I swept the climb (250 to 1,500) on the validation window under a rule I wrote down before running it: the largest step that still meets at least 70% of days. That was 1,500, the top of the range I tried, so a larger one might pass too. Then I ran it once on the final window.
TabPFN did not beat a percentile. On the validation window TabPFN's cap was ahead of the plain 30th percentile by 3.9 points; on the final window it was behind by 3.1. The sign flips, so on 33 people the two are a tie. I also tried a second feature set (everything relative to the person's own median) and picked between them on validation by a rule written before I saw the second result. It made no difference.
Gemma answered "rest". One word. The prompt asked for one short sentence, and the small model took that literally. Now Gemma writes the reaction with a few examples of Slumbrock's voice, code adds the tip, and one reply in three gets a rock joke. Gemma 4B once ended a reply with a curly quote and eighteen </div> tags; replies are now cut at a stray quote, brace or tag.
"Walked to work and back" got a tip for a sore back. Words like "back" and "head" now only count as body parts in context ("my back", "back is stiff").
My own statistics function would have crashed on real data. The bootstrap built a list of lists where it needed a flat list of days. The tests passed because every test person had the same number of days. A new test with uneven people caught it, and the fix was one word (extend, not append).
Not tested: whether these goals change what people do. A backtest replays what people did without the app. The public dataset is short (about two months) and from 2016; my own is one person.

Then I ran it on myself

The public set is 33 strangers from 2016. So I exported my own history: Google Fit steps since 2024 (1,028
days) and my Hevy log (633 workouts since 2022). My own data broke the app four times:

The importer refused my steps file. Google Fit calls the column Step count, not steps. The Takeout folder also has a raw stream per device, and adding them up would have counted every step twice, because my phone and my watch overlap. The importer now reads the right file and refuses the wrong ones with a message naming the right one.
Three years of history broke the goal. The app sent every stored day to the server, which refuses more than 800. It now sends the last 365.
Most of my steps are a phone in a pocket. The watch reached Google Fit on only 42 of those days, so a day with the phone left on a desk counts as a few hundred steps. Under 500 now counts as "not carried": rest, not a miss. I wrote that line down before running the backtest, and every upload gets the same cleaning now.
Then the import changed nothing. I loaded all 1,028 days into the live game and it still gave me 1,500. Imported days carry no goal, so the controller had nothing to replay and started from scratch, as if I had never walked. Now, like TCP reusing what it learned about a host it has seen before, the controller starts from your own 30th percentile of the last 28 imported days. On my history that is 4,100, just under TabPFN's cap of 4,150.

My last 90 days, held out (TabPFN v2 fitted 118 times, median 5.0 s each):

Goal	Goal met	Asks for	Met vs plain 30th percentile (95% CI)
Fixed 10,000	0.0%	301%	−68.9 pts (−75.6 to −61.5)
My 28-day median	52.2%	116%	−16.7 pts (−24.4 to −9.9)
My 28-day 30th percentile	68.9%	82%	(baseline)
TabPFN 30th percentile alone	68.9%	89%	+0.0 pts (−6.7 to +5.6)
Slow Start	71.1%	85%	+2.2 pts (−5.5 to +8.8)

With one person the interval resamples weeks, not people. A fixed 10,000 was met on none of my 90 days.
Slow Start and the plain percentile tie again, as they did on 33 strangers. On my data TabPFN alone met
exactly as often as the percentile while asking for a little more (89% of a usual day against 82%).

The workouts broke my exercise controller. It was built for a beginner's programme: three sets of eight
at one weight, plus 2.5 kg after a good session. I do not train like that. I work up to one heavy top set
(a deadlift day is 100 × 4, 140 × 3, 140 × 2, 100 × 6), so "repeat last session" was met 0% of the time,
and the controller "won" by cutting the weight to 12% of what I lift. The guardrail caught it, as it did
for steps. I changed the spec to score the top set instead, and reran:

Scored on the top set (exploratory)	Target met	Asks for vs last time
Repeat last top set	31.4%	100%
Add a step every session (2.5 kg, or one rep)	8.6%	106%
Controller	77.1%	82%

That design came after seeing my log, on the same log, so it is exploratory, not a held-out result. It is
35 sessions across six lifts.

One more thing only real use found: anyone who had watched the demo once was stuck in it. The Play button
kept reopening the demo, and the way out was hidden in a settings tab. I only noticed because I tried to
start for real with my own data.

Built with an agent, with four functions by hand

I built this with Claude Code under a spec-first workflow: brief, requirements, design and tasks, each
reviewed before code. Four core functions were set aside to write by hand:

Level	What	Written by
H1	The step controller	me, from a skeleton
H3	The evaluation statistics (goal level, people-resampled intervals)	me, from a skeleton
H2	The exercise controller	Claude, when I ran out of time
H4	The XP and stage rule	Claude, when I ran out of time

Why Does Open Innovation Matter?

Health data stays with you. Your steps, workouts and check-ins go only to a server I run, which processes each request in memory and keeps nothing. Everything is saved on your device.
The open version was the only usable one. TabPFN 2.5 and later are licensed for non-commercial use only. TabPFN v2 is Apache 2.0, so the app pins v2 and bakes the weights into the image. A predictor I can download, run on a plain CPU and check is one I can actually ship.
No price per call. A goal costs about five seconds of CPU (measured in the container with no network, 1 CPU and 2 GB). There is no per-request bill to make the "lazy" goal expensive.
Swappable and checkable. The predictor and the language model sit behind small interfaces, and the data, the weights and the evaluation script are all public, so anyone can rerun the tables above.

The Lazy Payoff

You make zero decisions. The app sets one step goal a day, and one target per exercise per session if
you lift.

In my last 90 days on Hevy I logged 43 workouts: 327 times I picked an exercise and a weight, and 685
working sets. Slow Start plans only the main lifts, so it takes about one decision in ten off me (35 of
them); the machines and cables are still mine. For steps it is every decision: one number a day, won 7
days in 10 on my data, where a fixed 10,000 was won on none. Lower goals are easier to win, which is exactly
why every table also shows how much each goal asks for.

Prize Categories

Best Use of TabPFN

TabPFN v2 is the receiver window: the half of the TCP analogy that knows what you can take tomorrow.

What it does on every goal. The game asks for today's goal, and TabPFN gets a handful of features (the last three days, the week's mean and minimum, the fortnight's median, the weekday). It is fitted in context on your own earlier days plus 400 rows from a public prior, so someone with a week of history is not starting from nothing. It returns quantiles, not a point. The cap is the 30th percentile, a level you reach about 7 days in 10, and the goal is min(controller window, cap).
Why TabPFN and not a model I train. There is nothing to train per person. One person has a few weeks of rows, far too few to fit a model, but TabPFN does in-context learning on exactly that kind of small table and gives calibrated quantiles out of the box.
Why v2. It is Apache 2.0. TabPFN 2.5 and later are non-commercial, so the app pins v2 and bakes the weights into the Docker image at build time.
How it runs. It runs on CPU with four estimators. I measured about 5 seconds per goal, 598 MB at peak and 2.9 s to load, in a container with no network, 1 CPU and 2 GB. On Render a goal takes 5 to 6.5 s. If it fails or times out, the cap falls back to 80% of your recent median, and the app says so.
How I tested it. Walk-forward on 33 people, with TabPFN refitted per calendar day on earlier days only. Two feature sets were picked on a validation window by a rule written before the second result came in. Against a plain "your own 30th percentile" it is a tie, and I report it as one. On my own last 90 days, with the product's own code, it ran 118 fits at a median of 5.0 s each. It met exactly as often as the percentile (68.9%) while asking for a little more of a usual day (89% against 82%).

Best Use of Gemma

Gemma 3 4B is Slumbrock's voice. You tell him how the day went ("upper body is really sore from weighted
pull ups yesterday"), and he answers in character.

Self-hosted. It runs on Ollama, on Render, with the model baked into the image so a restart never re-downloads it. No check-in ever leaves a server I run.
What Gemma decides, and what it does not. Under a JSON schema Gemma returns three things: an energy level, the body parts mentioned and one reply line. Code checks each of them:
- A body part is kept only if it is a known one and the person actually wrote it, so Gemma cannot invent a sore knee.
- The reply must be 4 to 40 words with no digits, so it can never state a number, a dose or a goal.
- Whether the day is excused comes from a word list with a negation check ("not sick" is not sick), not from the model.
- The recovery tip comes from a curated list chosen by code, so nothing medical is made up.
- The rock jokes ("You are, to be clear, talking to a rock.") are added by code, about one reply in three, never on a sick day.
Taming a small model. Gemma's first answer was one word: "rest". A few examples of Slumbrock's voice in the prompt fixed that. Gemma 4B once ended a reply with a curly quote and eighteen </div> tags, so output is capped (num_predict 240, maxLength 220) and cut at the first stray quote, brace or tag. Anything that fails the checks falls back to a template line, so a check-in never breaks.
Cost of thinking. About 15 seconds a reply on Render's 2 CPUs. I tried 1B on a smaller plan and its replies were noticeably flatter, so the 4B earned its plan.

Best Use of Render

One Blueprint (render.yaml) brings up the whole product: two services, a private link between them and
a health check.

slowstart, a web service (Docker, 1 CPU / 2 GB). One container serves the FastAPI API, the built game and site, and TabPFN v2. A multi-stage Dockerfile builds the TypeScript app with Node, then bakes the TabPFN weights into the Python image, so the service starts with no downloads. 1c-2g is the smallest plan that fits: TabPFN with torch peaked at 598 MB, too much for a 512 MB plan.
slowstart-ollama, a private service (Docker, 2 CPUs / 4 GB) with Gemma 3 4B baked in. It has no public URL. The web service reaches it over Render's private network, via fromService … hostport in the Blueprint.
Lessons the deploy taught me, all written into the Blueprint.
- The private service needs PORT=11434, or the hostport defaults to 10000 and every model call is refused.
- Inside the container llama.cpp sees the whole host, not the plan, so LLAMA_ARG_THREADS=2, LLAMA_ARG_CACHE_RAM=0 and LLAMA_ARG_NO_REPACK=1 keep it inside 4 GB.
- OLLAMA_KEEP_ALIVE=-1 keeps the model loaded between check-ins.
Shipping by pull request. Both services deploy from main with auto-deploy on, behind /api/health. Every fix in this post was a merged PR that was live a few minutes later, including the ones my own data forced on deploy night.
Stateless on purpose. The server keeps nothing: every request carries the history it needs, and your data lives on your device. A restart or a redeploy loses no one's progress.

Holdfast: a webhook safety net where Gemma explains what broke and code decides what happens

Tanay — Sun, 18 Oct 2026 13:06:25 +0000

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

What I Built

My day job is message queues in containers. The first rule there is boring and absolute: a message isn't acknowledged until it's safely stored. Lose power a millisecond later and it's still there.

Webhooks don't work like that. Stripe or GitHub sends your app a message, and if the app is down, slow, or chokes on a field that was renamed overnight, the message is usually just gone. The person who finds out is the shop owner, two days later, asking why three payments never showed up.

Holdfast is that queue rule, turned into a product for the people who get that phone call: freelance developers and small agencies who look after integrations for a handful of clients. It sits between the provider and the app and:

Saves every webhook to disk before saying "got it".
Checks the signature, and keeps forged or replayed messages aside.
Delivers patiently: retries when the app is down, holds when a retry won't help.
Explains what broke in two voices: a plain sentence the client can read, and a precise fix for the developer. Gemma writes both; code checks every word.
Sends held messages again, never twice.

Who pays: the freelancer who maintains "the Stripe thing" for five small clients. One lost payment webhook is a lost order and an awkward conversation. Holdfast turns that into a note they can forward:

Kabir's ₹1050 payment for Ginger chai, 500 g couldn't reach Chai & Co. because the sender changed how it sends customer information. Holdfast is keeping the message safe, and it can be sent again once the app is updated to expect the new format.

That's a real answer from the deployed site, written by Gemma 3 4B running on Render.

Demo

Live: https://holdfast-o9ba.onrender.com

It has two modes, switchable from the header:

Demo (/demo, no sign-up): Chai & Co., a pretend tea shop with made-up customers. Seven buttons break it on purpose: the shop goes down, a field is renamed, a payment arrives twice, a signature is forged, an old payment is replayed. The relay, retries, checks and explanations are the real engine.
Live (/live): sign in with GitHub, pick one of your repositories, and Holdfast adds itself as the webhook. GitHub's test ping arrives within seconds. If you don't have an app, deliver to Holdfast's built-in test app and switch it to "Server down" or "Turns messages away" to watch a real webhook get held, explained and resent.

Landing Page:

Demo:

Event Gemma:

One honest note: Gemma runs on two CPU cores, so an explanation takes up to a minute and a half (48 s and 83 s in my last two live runs). The page shows the built-in rules' answer instantly and swaps in Gemma's when it's ready.

Code

Tanay3484 / holdfast

A safety net for webhooks: stores every event, holds what your app fails on, explains why with an open-weight model, and resends safely.

Holdfast

A safety net for webhooks. Holdfast sits between a provider (Stripe, GitHub) and your app. It stores every event before acknowledging it, holds the ones your app fails on, explains why in plain words with an open-weight model, and resends them safely once the problem is fixed.

Built for the Hacktoberfest 2026 Open-Source AI Challenge, Week 2: Side Hustle.

How it works

provider ──▶ /in/{route} ──▶ check signature ──▶ save to disk ──▶ "got it"
                                                      │
                     deliver to your app ◀────────────┘
                       ├─ accepted      → done
                       ├─ worth a retry → wait a little longer each time
                       └─ won't work    → hold it safely
                                             │
                     code collects the facts ┘  (signature, every try, what changed since the last success)
                     Gemma names the cause from a fixed list and explains it; code checks every word
                     resend: never twice, never anything that failed its signature check

Code decides, the model explains.…

View on GitHub

Go, about 5,900 lines plus 1,550 lines of tests (59 tests). Every feature has a spec in specs/ with numbered requirements.

How I Built It

Open-weight model: Gemma 3 4B, served by Ollama in a private service next to the app. Stack: Go standard library, SQLite (pure-Go driver), server-rendered HTML, a little vanilla JS. Hosting: a single Render Blueprint (more below).

Code decides, the model explains

The rule I held to: the model never decides what happens to a message. Retries, holds, duplicate detection and resends are plain, tested Go. Gemma gets the facts code collected (signature result, every delivery attempt, the app's error, what changed in the payload) and does two jobs:

pick a cause from a fixed list of eight, under a JSON schema, and
write the explanation.

Then code checks what it wrote. The client summary is rejected and replaced with the built-in rules' wording if it contains jargon ("HTTP", "payload", "endpoint", an error number) or promises something nobody did. Titles always come from code.

The bug that taught me the most

First version, renamed-field scenario. Gemma got the cause right, but the client summary said:

A payment notification failed to reach the Chai & Co. system. The notification is being kept safe and reviewed.

Nobody was reviewing anything. Worse, the developer note said the app "now requires customer_id", which is backwards: Stripe changed, the app didn't.

The fix wasn't a better prompt alone. It was moving more work into code:

Code finds the rename. A shape-diff walks both JSON bodies and spots that data.object.customer_id disappeared while data.object.customer.id appeared. That's one rename, with a direction. Gemma is told "the sender now sends X where it used to send Y; the app did not change" instead of a raw list of paths.
The summary has a required shape: what happened to this payment (who, how much), why in everyday words, what happens next.
A Promise check rejects "being reviewed", "will resend", "our team is…".
The developer fix must name the field that moved, or the rules' fix is used.

After the fix, on the same scenario:

For your developer: The sender now uses data.object.customer.id instead of data.object.customer_id. Change the app to expect data.object.customer.id.

Model size, measured

Model	Where	Result on the renamed-field case
Gemma 3 1B	laptop	Wrote "the app will resend the held events" (a promise) and told the sender to change. The checks now catch both and fall back to the rules' answer.
Gemma 3 4B	laptop GPU	Named the customer and amount, explained the change plainly, and pointed at the exact field. About 16 s.
Gemma 3 4B	Render, 2 CPUs	Same quality. 92 s for one explanation.
Gemma 3 4B	Render, after the fixes below	Two live runs, both explained by Gemma: 48 s and 83 s.

On a laptop CPU with two threads, one explanation was 740 prompt tokens read in 15 s and 115 tokens written in 14 s. That's why the page shows a rules answer first.

How I built it: an unlock game

I built this with Claude Code, spec first. The four core pieces started as stubs I had to write by hand, each a "level" with known-answer checks. go run ./cmd/unlock prints a progress board, and while a level was locked, every part of the website it powered showed a "WIP: write this file to reveal how this will look" tile. Writing a file literally revealed part of the site.

Being honest about who wrote what (it's recorded in tasks.md):

Level 1, signatures: I wrote GitHub's HMAC check. Stripe's was started by me and finished by Claude.
Level 2, retry policy: written by me (backoff, Retry-After, the hold rules), polished by Claude.
Levels 3 and 4, shape diff and resend plan: written by Claude at my request. Level 3 was a worked example to teach me recursion, which I'd stalled on, and level 4 was the last night before the deadline.

Two safety details I'm glad I didn't skip

Server-side request forgery. Live mode lets you type the URL Holdfast forwards to. Without care, anyone could point it at holdfast-ollama:11434 or a cloud metadata address and read the answers on the event page. Destinations are checked when saved and every connection is checked again at dial time, so a hostname that later resolves to a private IP is still refused.
Duplicates. Providers deliver at least once. The resend plan sends each event once, in arrival order, never one that was already delivered, and never one whose signature failed.

Why Does Open Innovation Matter?

The data is the business's customers. Payment webhooks carry names, amounts and addresses. With an open-weight model on the same private network, none of it goes to an AI company, and the freelancer can tell their client that truthfully.
No per-message bill. A small shop's integration might send hundreds of events a day. One small model on one server explains every failure for a flat cost.
I could look inside the failure. When Gemma promised a review that wasn't happening, I could see exactly what it was given, change what code tells it, and constrain its output with a JSON schema. The fix was engineering, not hoping a vendor's model changes.
Swappable. The model is one setting (HF_MODEL). I measured 1B against 4B and chose on evidence.

My Agent Session

Built pair-programming with Claude Code: spec first (brief, requirements, design, tasks, each approved by me), then implementation task by task, with subagents for coaching me on my levels, writing specs, and drafting this post. The coach was told never to write my code, only give hints and review.

Building Holdfast: a webhook safety net with Gemma

You

Status is approved. Set up the rest today: the frontend website, and leave certain things as "WIP: work on this file to reveal how the website will look", something like a game for me, where every file I code, I unlock a bit of the website. Obviously the coding bits are still to be done by me.

Agent

Plan: the four core pieces (signature checks, retry policy, JSON shape diff, resend plan) become documented stubs that return wip.ErrLocked. Each is a 'level' with known-answer checks in internal/unlock. The relay falls back to simpler behaviour while a level is locked, and every part of the site a locked level powers renders a WIP tile naming the file to write. go run ./cmd/unlock prints the board.

▸ Write internal/verify/verify.go (stub + contract + GitHub's documented known answer)

Input

internal/verify/verify.go (stub + contract + GitHub's documented known answer)

Output

File created

▸ Bash go run ./cmd/unlock

Input

$ go run ./cmd/unlock

Output

HOLDFAST · UNLOCK BOARD  0 of 4 levels
[··········]  Level 1  Signature check  LOCKED
  next → open internal/verify/verify.go (H1)

Then the engine: SQLite store that commits before the relay answers 200, a delivery worker with a one-try fallback, rule-based diagnosis plus Gemma via Ollama under a JSON schema, a client note, and the website with a live demo shop (Chai & Co.) that visitors can break on purpose.

▸ Bash fire every demo scenario at the local server, read the dashboard

Input

$ fire every demo scenario at the local server, read the dashboard

Output

3 payments held safely … What happened: the app's server was down.

You

So shouldn't we first have some kind of struct present that will be needed when unmarshalling?

Agent

No struct: Of has to accept any JSON. Unmarshal into any, then a type switch over map[string]any, []any, string, float64, bool and nil tells you what each node is. The rest is a small recursive walk that records the kind at each path.

You

Just write it for me so I can understand what you're trying to tell me. I will do the next one on my own.

Agent

▸ Edit internal/shape/shape.go: walk(s, path, v) records the kind, then recurses int...

Input

internal/shape/shape.go: walk(s, path, v) records the kind, then recurses into object keys (path.key) and array items (path[]); record() marks Mixed when array items disagree; Diff compares two shapes and sorts by path

Output

Level 3 UNLOCKED (7/7 checks)

It is the folder-listing idea: write down what this thing is, and if it contains other things, call walk again for each with a longer path. tasks.md records that I wrote this level at your request.

You

Ok just check and lmk if Function 1 is ok?

Agent

▸ Bash go run ./cmd/unlock -v

Input

$ go run ./cmd/unlock -v

Output

Level 1  Signature check  4/10 checks
✓ GitHub: accepts GitHub's own documented example
✓ GitHub: rejects a body changed after signing
✓ GitHub: reports a missing header
✓ GitHub: rejects a header without sha256=

GitHub is correct, and decoding the hex and comparing raw bytes with hmac.Equal is better than comparing hex strings. The remaining six checks are Stripe's: same seal, but over "t.body", any v1 may match, then a freshness check.

You

Gemma only says: "A payment notification failed to reach the Chai & Co. system. The notification is being kept safe and reviewed." Is this temporary? Because come on it should say more than that.

Agent

▸ Bash read the held event's page

Input

$ read the held event's page

Output

For your developer: The app is now requiring a 'customer_id' field, which was previously absent…  (backwards: the sender changed, not the app)

Not temporary: the prompt only asked for 'two short sentences, no jargon', nothing checked for promises ('reviewed'), and Gemma was handed raw paths and guessed the direction. Fix by moving work into code: detect renames (customer_id → customer.id) and tell the model the sender changed; require what happened / why / what next; a Promise check; and the developer fix must name the moved field or the rules' fix is used.

▸ Bash renamed-field demo again on gemma3:4b

Input

$ renamed-field demo again on gemma3:4b

Output

Nisha's ₹1050 payment … couldn't reach Chai & Co. because the sender changed how they send customer information. Holdfast is keeping the message safe and it can be sent again once the system is updated.
For your developer: The sender now uses data.object.customer.id instead of data.object.customer_id.

▸ Bash same demo on gemma3:1b

Input

$ same demo on gemma3:1b

Output

"The app will resend the held events." / "Ensure the sender updates the customer ID field."  → guards now replace both

You

I want to go 4b since the good answers is what we want. How will we host it on Render though? I want to mimic my Week 1 setup.

Agent

Same shape as Week 1: a public web service plus a private Ollama service with the model baked into its image, now on 2c-4g because gemma3:4b needs about 3.5 GB loaded. Measured on a CPU with 2 threads: 740 prompt tokens in 15 s, 115 output tokens in 14 s, so the page shows the rules' answer at once and swaps in Gemma's when it arrives.

▸ Edit relay: save the rules' diagnosis first (pending), replace with the model's; r...

Input

relay: save the rules' diagnosis first (pending), replace with the model's; resume pending ones after a restart

Output

tests pass

You

Can you do Level 4 for me? And then overhaul the website since it's no longer a game. Can we have two modes, Demo and Live? Live will be for users to connect GitHub. I don't have a Stripe account, so we will be honest about it in our submission.

Agent

▸ Edit internal/replay/replay.go: DedupeKey (GitHub delivery id, Stripe event id, el...

Input

internal/replay/replay.go: DedupeKey (GitHub delivery id, Stripe event id, else sha256 of body); Plan sorts a copy by arrival, sends each key once, never a forged or already-delivered event

Output

Every level unlocked. Holdfast is ready to ship.

Live mode: GitHub OAuth (admin:repo_hook only), Holdfast adds the webhook to the chosen repo, delivery to the user's app or a built-in test app that can be made to fail. Routes become dynamic; user-typed destinations go through a guard that refuses private addresses at save time and again at dial time, so nobody can point Holdfast at its own Ollama service. Tokens and webhook secrets are sealed with AES-GCM. Stripe connects by hand, and the site says so.

▸ Bash go test ./internal/netguard/

Input

$ go test ./internal/netguard/

Output

ok  (refuses 127.0.0.1, 10.x, 169.254.169.254, holdfast-ollama:11434; dial-time check refuses loopback)

You

The GitHub login looks a bit weird. Also there's too much text on the demo and live page. We want it attractive to customers so they will pay.

Agent

The page in the screenshot was rendering with almost no CSS: the stylesheet was linked as app.css?v=dev, so the browser kept an old cached copy. Assets are now linked with a hash of their contents. Then the copy: Live becomes a headline, one line, a dark 'Continue with GitHub' button, three chips and three step cards; Demo becomes 'Break the shop. Lose nothing.' with short button labels.

You

For the how it works section, can we add an animation rather than textboxes? Makes it easier for people to understand.

Agent

A 15-second SVG/CSS loop: a payment travels Stripe → Holdfast → the shop, is saved, checked, finds the shop down, is held, explained, then sent again while a duplicate is crossed out; five captions light up in step. Headless screenshots showed it frozen until I added --disable-threaded-animation: transform and opacity animations run on the compositor, which virtual time doesn't drive.

You

Deployed. GitHub seems to be working fine.

Agent

▸ Bash render logs (holdfast)

Input

$ render logs (holdfast)

Output

WARN model unavailable; used rules err="ollama: Post \"http://holdfast-ollama:10000/api/chat\": dial tcp …:10000: connect: connection refused"

▸ Bash render logs (holdfast-ollama)

Input

$ render logs (holdfast-ollama)

Output

ollama ready with gemma3:4b
Detected service running on port 11434

Ollama is healthy on 11434, but the Blueprint's fromService hostport used Render's default port 10000. The rules answered every held event, so the site stayed usable. Fix: PORT=11434 on the private service.

▸ Bash after the redeploy: send a renamed-field payment to the live site

Input

$ after the redeploy: send a renamed-field payment to the live site

Output

after 92s: Kabir's ₹1050 payment for Ginger chai, 500 g couldn't reach Chai & Co. because the sender changed how it sends customer information…
Explained by Gemma, checked by code.

My First User

My first user is a real app with a real repository: Tasklet, a small todo app I built (source) that turns GitHub issues into todos. It's strict on purpose, like a real handler, and it has a maintenance switch that makes it answer 503. I signed in to Holdfast's Live mode with GitHub, connected Tanay3484/tasklet, and pointed it at Tasklet's webhook address. My coding agent ran the rest from the command line while I was out, and I checked the results when I got back.

Step	What happened
Connect the repo	Holdfast added the webhook. GitHub's test ping was acknowledged in 0.27 s.
Open issue #1	GitHub → Holdfast acknowledged in 0.82 s. The todo appeared in Tasklet within 4 s.
Tasklet in maintenance, open issue #2	Holdfast tried 5 times in 34 s (waiting 2, 4, 8, 16 s), got 503 each time, and held it. Gemma explained it in 40 s.
Close issue #1	The todo was ticked off within 4 s.
Maintenance off, then "Send all held again"	I pressed it in Live mode. Issue #2's todo appeared in Tasklet, once. Nothing was lost while the app was down.

One detail I'll own: Tasklet runs on Render's free plan, which doesn't keep a disk, so its todos reset whenever it falls asleep. That's why issue #1's todo had disappeared by the time I resent #2. Holdfast's copy of every message was still there.

Did anyone pay? No. My first user is me and my own app, so I won't claim a sale. What the run convinced me of is the thing I'd charge for: I switched an app off, opened an issue, and nothing was lost, and I got a sentence explaining why it was held that I could forward to a client. What I'd build next: an email or Slack alert the moment something is held, one-click Stripe sign-in, and a share link for the client note.

Something real from deploy day: on the first deploy, every Gemma call failed with connection refused on holdfast-ollama:10000. Ollama was healthy on port 11434, but Render's service-to-service address used its default port. The rules took over automatically, so the site stayed fully usable, which is exactly the fallback I designed for. One line in render.yaml (PORT=11434) fixed it.

Then two more, the same afternoon:

Out of memory. Render killed the Gemma service. Inside the container, llama.cpp sees the whole host (60+ GB, 16 CPUs), not my 4 GB plan, so it kept a prompt cache that could grow to 8 GB and a second, repacked copy of the weights. Three LLAMA_ARG_* settings (no prompt cache, no repack, 2 threads) brought it back under 4 GB.
A runaway answer. Some diagnoses ran on for hundreds of tokens and never closed their JSON. I reproduced it on my laptop's CPU with Render's exact settings: in 3 of 5 runs Gemma tried to end a string with a curly quote (”}), which JSON treats as ordinary text, so it never stopped and started repeating itself. A second cause: Go wrote the JSON format's fields alphabetically (cause, fix, summary), so Gemma poured the whole story into the developer's fix and left the owner one line. The fix: length limits on each field, code that cuts a field at the stray ”}, a check that the summary ends like a sentence, and the fields listed as cause, summary, fix. Before: 2 of 5 runs usable. After: 4 of 4, in 16–40 s.

Each time, the visitor still got a correct, plain-language answer from the rules. Gemma makes the explanation better; it was never the thing keeping a payment safe.

What isn't built: one-click Stripe sign-in. Stripe Connect needs a Stripe platform account, which I don't have, so Stripe connects by hand. You paste one address into Stripe's webhook settings and its signing secret into Holdfast. The site says so plainly.

Prize Categories

Best Use of Render. Render is the AI runtime: one Blueprint runs the public Go service (with a persistent disk for the event store) and a private Ollama service with Gemma baked into the image, talking over Render's private network. The model is never exposed to the internet.
Best Use of Gemma. Gemma 3 4B writes every explanation and client note. Its output is constrained to a schema and checked by code, and I measured it against 1B to choose the size.

Golden Hour: an open model that finds your 40 minutes outside, and where to spend them

Tanay — Sun, 11 Oct 2026 10:08:21 +0000

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

What I Built

I don't stay indoors because I don't want to go out. I stay in because two small decisions are easy to put off: when, and to do what. Weather apps tell me what it's like outside. Nothing tells me "go at 18:00, and here's where."

Golden Hour does exactly that, and nothing else:

Tell it when you're free today. Or don't, and it assumes "from now until sunset".
It picks your best 20–40 minutes. It reads the hourly forecast and sunset for where you are, scores every possible slot, and explains its choice: "dry", "golden hour", "chilly (13°C)".
Pick up to three hobbies, like photography, history or coffee outside, and it finds the top 5 real places within walking distance from OpenStreetMap.
Gemma, an open-weight model running on my own server, writes one line for each place: what to do there, right now, in this light and this weather.
You get a countdown and a calendar invite with a 10-minute reminder. Then you close it.

It's deliberately not an app you spend time in. Success is closing the tab.

Demo

Try it: https://golden-hour-ahl6.onrender.com

(best on a phone: allow location, or search for your city)

Here's a real plan it made for a morning in central Pune. I picked photography and history, and left my free time empty:

06:30–07:10, 94/100. Dry and calm, and it only loses points for being 26 °C at dawn. Then the five places within a 13-minute walk:

Shaniwarwada, the 18th-century fort, is three minutes away, and Gemma's line for it was "Start with a quick photo of the surrounding architecture to capture the morning ambiance." Two of the lines, for the second park and the memorial, are my hand-written templates: the model's attempts didn't pass the checks I describe below, so the app quietly used safe lines instead.

Code

Tanay3484 / golden-hour

Your best 20-40 minutes outside today, planned by an open-weight model. Hacktoberfest 2026 'Touch Grass' challenge.

🌅 Golden Hour

Your best 20–40 minutes outside today, and one small thing to do with them.

Tell Golden Hour when you're free. It checks the hourly forecast and sunset for where you are, picks the nicest window to be outside, and finds the top 5 real places within walking distance that suit your hobbies, from OpenStreetMap. An open-weight model (Gemma, served by Ollama) writes one line for each on what to do there right now. You get a countdown and a calendar invite with a 10-minute reminder.

Built for the DEV Hacktoberfest 2026 Open-Source AI Challenge, Week 1: "Touch Grass".

How it works

Browser ──▶ FastAPI ──▶ Open-Meteo (forecast + sunset, open data, no key)
                │
                ├─ scoring.py   deterministic: every 20–40 min slot in your free time, scored 0–100
                │               (rain, temperature, wind, UV, +15 for golden hour)
                │
                ├─ places.py ──▶ OpenStreetMap (Overpass):

…

View on GitHub

How I Built It

Stack: FastAPI · vanilla JS (about 30 KB, no build step) · Ollama serving Gemma 3 (gemma3:1b in production, gemma3:4b on my laptop) · Open-Meteo for weather and OpenStreetMap for places (both open data, no API keys) · two services on Render.

free time + forecast  ──▶  plain Python picks the window      (tested, explainable)
hobbies + location    ──▶  OpenStreetMap → Python ranks top 5  (no model involved)
window + 5 places     ──▶  Gemma writes one line per place     (JSON schema, validated)

Building it taught me four things I didn't expect.

1. Let math pick the time. Let the model write.

My first instinct was to hand Gemma the whole forecast and ask "when should I go out?". I didn't, for three reasons: a 1B model on a shared CPU is slow, it's bad at arithmetic over 48 rows of numbers, and I wanted to be able to explain why it chose 18:00.

So the window is picked by under 200 lines of plain, tested Python. Every quarter-hour slot in your free time gets the worst weather of the hours it touches, then a score: start at 100, lose 0.8 points per % chance of rain, 3 per °C outside 15–24, 2 per km/h of wind above 20, 5 per UV point above 6, and gain 15 if it overlaps the hour before sunset. The reasons on the card come from the same list of factors as the score, so the explanation can't disagree with the number.

Writing tests caught a bug no demo would have: on a perfect day every slot scores 100 after capping, so the golden-hour bonus vanished and the earliest slot won. You'd only notice on the one perfect evening you actually wanted. A tie-break that prefers golden hour fixed it.

2. Small models need guardrails, not just better prompts

Gemma only does the creative part, and its answers have to match a JSON schema (Ollama's structured outputs make this reliable even at 1B). Testing it locally on real data was humbling:

What Gemma did	What fixed it
With no location, it sent me to a nonexistent "Elm Street"	It isn't allowed to name places it wasn't given; it describes kinds of places instead
At a 70% chance of rain, it suggested an open field	"Match the weather" was too vague. Now the first step must say how to stay dry
Asked to "pick the best 5" of 13 real places, it returned the first five in list order. 4B called a Berlin memorial the "Frauenkirche"	Code ranks the places (hobby, walking time, weather, variety). Gemma only describes them, using facts from OpenStreetMap
It wrote a park's line about a statue elsewhere on the list	Gemma must echo each place's name, and the server rejects any line that doesn't match, names another place, or borrows another place's facts. Rejected lines become a hand-written template

The honest result: gemma3:1b now puts every line on the right place, but still adds the odd plausible detail ("a pastry" at a café). gemma3:4b doesn't, but it's about five times slower. On a 1-CPU server, I chose fast, and I wrote the gap down in the spec instead of hiding it.

3. Open data is free, but not effortless

The public OpenStreetMap query servers (Overpass) are a shared, volunteer-run resource. In one evening of testing, two of three public instances failed for every city, and the main one kept answering "server too busy" for Pune and Mumbai while Berlin worked fine.

The first fix was one directive. Overpass decides whether to admit a query based on how much memory it might need, and the default is 512 MB. Declaring 64 MB ([maxsize:67108864]) got Pune through in 3 seconds.

Then I deployed, and the live site found zero places, twelve times in a row. The same query from my home connection returned 44 places in 3 seconds. Overpass limits how many queries each IP address can run, and my Render server shares its outbound IP with a lot of other people's apps. So now, if the server can't reach OpenStreetMap, your browser asks it directly, with the exact same query, and hands the raw results back to the server to rank. Every visitor brings their own rate limit. Anything a browser sends back is treated as untrusted and never cached, so nobody can plant fake places for the next person. If both routes fail, you get a single Gemma-written activity instead, and the page never breaks.

For privacy, OpenStreetMap only ever sees the centre of your ~1 km area. Exact walking times are computed on my server, and nothing is stored.

4. One setting doubled my speed on Render

render.yaml is a two-service Blueprint: a public FastAPI web service, and a private Ollama service with Gemma baked into its Docker image. The web app reaches it over Render's private network, so the model has no public endpoint at all.

The first live run was painfully slow: 38–80 seconds per suggestion, about twice what I'd measured in Docker with the same 1-CPU limit. The cause was one setting. Ollama sizes its thread pool from the host machine's CPU count, so on a big shared server it ran dozens of threads fighting over the single CPU my plan provides. Setting num_thread to 1 doubled the speed: suggestions now usually take 15–30 seconds instead of up to 80. If you run a small model on a small cloud instance, check this first.

Built spec-first, with an AI pair

I built Golden Hour spec-first: requirements with testable acceptance criteria, then a design, then a task list, each approved before any code was written. It's all in specs/. Every task had an owner: me, or my AI pair, Claude Code.

I wrote the first scoring rules myself. Then my GRE landed in the same week, and I handed most of the build to Claude, working from the approved spec while I reviewed and merged. Every change of plan, from the golden-hour tie-break to the browser fallback for OpenStreetMap, went into a spec changelog before it went into the code. So the repo shows why things changed, not just what. It's covered by 154 Python tests, a Node test for the countdown and calendar export, and CI on every pull request.

Why Does Open Innovation Matter?

Because "when are you free" and "where are you" are personal. A closed-API version of this app would send your location and schedule to a third party every time you opened it. Here, the model runs on a server I control and never receives coordinates at all. Weather and places come from open data, with no keys and no accounts.

Because it should be cheap enough to just exist. An app that nudges you outside once a day shouldn't come with a per-token bill or a usage cap. The whole production stack is two small CPU services on Render, about $32 a month, with no metered API anywhere.

Because I got to choose the trade-off. Same code, same prompt: 4B on my laptop for richer lines, 1B in production to fit a small box. Switching is one environment variable. With a closed model, someone else decides the size, the price and whether it's still available next month.

Because you can see why it said 18:00. The scoring rules, the prompts, the guardrails and the model weights are all open. If it ever sends you out into the rain, you can find the exact rule that let it happen, and send a pull request.

What's Next

An installable phone version with a local "your golden hour starts in 10 minutes" notification, so it reaches you even when the tab is closed
Running Gemma on the phone itself, so it works offline and fully privately
The field test I owe this project, right after the GRE

Prize Categories

Render: Render is the project's AI runtime. Gemma runs on a private Render service via Ollama, behind a public web service, deployed from a one-click Render Blueprint.
Gemma: Gemma 3 writes every activity suggestion and every place line: gemma3:1b in production, gemma3:4b locally, constrained to JSON schemas.

Order Taker: turning "kal subah 2 box brownies" into real orders with open AI

Tanay — Sun, 04 Oct 2026 12:55:48 +0000

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

What I Built

Picture the home baker down your street. They take every order on WhatsApp:

Priya: Hi aunty! Can I get 1 kg chocolate truffle cake for Sunday evening? Eggless please 🙏
Priya: Write "Happy Birthday Arjun" on it
Rahul Bhaiya: 2 box brownies kal subah, address 14B Lakeview Apts
Rahul Bhaiya: sorry make it 3 boxes
Meena: Good night aunty 😊
Sneha: 12 cupcakes vanilla + 6 red velvet, Saturday 4pm pickup. My number 98450 12345

That's six messages in a mix of English and Hindi. There's an edit ("make it 3 boxes"), relative dates ("kal", "Sunday"), a pickup, and someone just saying good night. Multiply that by a busy festival week and orders get missed, quantities get mixed up, and customers keep messaging "aunty, is my cake ready?"

Order Taker is built for that person: someone who is great at baking, not at spreadsheets, and who runs the whole business from one WhatsApp chat.

The shop owner pastes (or uploads) the WhatsApp chat. A small team of AI helpers reads it, and a friendly "What's happening" box explains each step in plain English as it goes. Each order shows up as a card to Accept, Edit or Discard, with anything odd flagged: "Delivery or pickup? No address was given."
Accepted orders move along with one big thumb-sized button: Received → Confirmed → Preparing → Ready → Delivered. There's a per-day prep list ("3 boxes brownies, 2 kg chocolate cake") and a CSV export.
Customers log in from their phone with their number and a PIN that the shop sends them on WhatsApp. They see a progress bar for their order, and they can change or cancel it in the app. Before the shop confirms an order, changes apply straight away. After that, they go to the shop owner as a request to approve, shown old → new.

The whole thing runs on the shop owner's laptop. Customers' phones reach it over the same Wi‑Fi.

Demo

The app is deliberately not hosted anywhere: customer names, phone numbers and home addresses never leave the laptop. To try it yourself, follow the 3-step setup in the README with samples/sample_chat.txt.

Update: from one laptop to a fully deployed app

Keeping it on the laptop was a choice for this first version, not a limit of the design. The same code can become a normal hosted web app that customers open from anywhere, not just on the shop's Wi‑Fi:

The web app is a standard FastAPI service. Every machine-specific setting is already an env var (ORDER_DB, ORDER_PORT, ORDER_PUBLIC_URL, OLLAMA_URL), so it can run on Render, Fly.io or a small VPS behind HTTPS with secure-only cookies.

The data moves from one SQLite file to a managed Postgres database. The numbered migrations are plain SQL, so they carry over.

The AI stays open. OLLAMA_URL can point to an open-weight model on a GPU server you control, or even back to the shop's own laptop through a private tunnel. Then the model still runs on the owner's machine, while customers get a public link.

Next steps after that: WhatsApp Business webhooks so orders arrive automatically instead of being pasted, an SMS or WhatsApp one-time code instead of a shop-issued PIN, and one install serving many home businesses.

The trade-off is honest: once it's hosted, customer data lives on a server instead of only on the laptop. That's why the project's specs treat it as a deliberate change to its "local-first" rule. The owner should choose it on purpose, not have it happen by accident.

Code

Tanay3484 / order-taker

Turn messy WhatsApp orders into a clean order board for home bakers, with local multi-agent AI (Ollama) so customer data never leaves the laptop.

title	Order Taker
emoji	🧁
colorFrom	pink
colorTo	yellow
sdk	docker
app_port	7860
pinned	false
license	mit
short_description	Local AI agents turn WhatsApp orders into a bakery board

Order Taker 🧁

Turns messy WhatsApp order messages into clean orders for a small home business. The shop owner pastes the chat, a team of small AI helpers reads it, and customers can log in from their phones to see where their order is.

Everything runs on the shop owner's laptop with an open-weight model via Ollama, so customer names, numbers and addresses never leave the machine.

What it does

Shop owner (admin): paste or upload the WhatsApp chat. Watch a plain-English "What's happening" feed while it's read. Check, edit and accept each order, then move it along: Received → Confirmed → Preparing → Ready → Delivered.
Customers: log in with their phone number and a PIN the shop sends…

View on GitHub

How I Built It

Open-weight model, running locally: qwen2.5:7b through Ollama, on an ordinary laptop with a 4 GB GTX 1650. Every model call uses Ollama's structured output with a JSON schema, and the result is validated with Pydantic before anything is stored.

Multi-agent intake, without a framework. The flow is a fixed pipeline, so plain asyncio was enough (about 150 lines), and it let me attach a progress message to every step:

pasted chat ─▶ Master (plain code): split by person, skip messages already read,
                spot pure "good night / thank you" without any AI
                  │  one track per person, all at the same time
                  ├─▶ [Sorter, small model*] ─▶ [Extractor, 7B] ─▶ [Checker, plain code] ─▶ draft card
                  └─▶ …

Master splits the chat by sender and skips messages it has already handled, so you can paste the whole chat every evening and only new messages get read.
Extractor (one per person) sees only that person's messages and their open orders. That's how "sorry make it 3 boxes" becomes a change to the existing order instead of a duplicate.
Checker is just rules: missing date, missing address/pickup, missing phone, duplicates.
The AI proposes, a human decides. Nothing becomes a real order until the shop owner taps Accept.

The most interesting lesson: let code do what code is good at. On the first real run, the 7B model read Priya's "Sunday" as a Thursday and Sneha's "Saturday" as a Wednesday. Small models are bad at calendar arithmetic. So now the model only copies what the customer wrote ("Sunday", "kal", "5th Oct"), and a small lookup table in Python turns it into a date, counted from when the message was sent. Same with phone numbers: a regex finds "My number 98450 12345" every time; the model didn't.

Honest numbers on my laptop (the model only partly fits on the GPU, so Ollama runs one request at a time):

	Old (one big call)	Multi-agent
First order ready to check	~41 s	~20 s
Whole chat done	~41 s	~55 s
Dates, phone, chit-chat correct on the sample	✗	✓

So on modest hardware the win is time to first order and correctness, not total time. On a machine with more VRAM and OLLAMA_NUM_PARALLEL set, the per-person tracks really do run side by side. The repo includes scripts/bench_intake.py so anyone can measure their own machine.

No "Processing…" spinner. A spinner that sits there for a minute makes non-technical users think the app is broken. Instead, the progress box narrates every step: "Meena is just chatting. Nothing to order.", "Still working on Priya's messages, nearly there…", "All done in 53 seconds: 3 things to check, 1 just chatting." These messages come from fixed templates, never from raw model output. A test fails the build if any of them contains words like "JSON", "API", "token" or "Ollama".

Spec Driven Development. Before writing code, I wrote a short constitution (local-first, plain English, AI proposes / human decides, mobile-first) and five feature specs with numbered acceptance criteria. Every one of the 154 tests names the criterion it covers (INT-21, TRK-23…). When the real model proved a spec wrong (the dates!), I updated the spec first and then the code. It's all in specs/.

Stack: FastAPI, SQLite, Jinja2, a little vanilla JS, Server-Sent Events for the live feed. No CDNs, no external calls.

Why Does Open Innovation Matter?

For this user, a closed API wasn't really an option:

Privacy: these chats are full of customers' phone numbers and home addresses. With an open-weight model running locally, none of it leaves the laptop. There's no third-party processor and nothing to explain to customers.
Cost: a home bakery might get 40 messages a day. Any per-token bill is real money for a tiny business. Local inference costs nothing per message.
It works when the internet doesn't: the app and the model run on the laptop, and phones only need the home Wi‑Fi.
Control: I could look at exactly where the model failed (weekday maths, optional JSON fields) and design around it. When I needed every field filled in, I tightened the JSON schema sent to Ollama. Swapping to another model is one env var (ORDER_MODEL=llama3.2).

And because the app is MIT-licensed, any other home business can run it, and any developer can add their language's words for "tomorrow".

My Agent Session

I built this pair-programming with Claude Code as my coding agent, using a spec-first workflow: we agreed the constitution and specs together, then it implemented feature by feature against them and ran the real model to check its own work.