If you haven’t fallen down this hole: kombucha is sweet tea fermented by a SCOBY (a rubbery pancake of yeast and bacteria) into something tart and fizzy. It’s a living hobby — the culture is alive, every batch is a little different, and the only way to get good is to pay attention and remember what you did.

I was not remembering what I did. Brew dates lived in my head, taste notes lived nowhere, and “which jar was the ginger one again?” was a genuine question I asked myself out loud, to a fridge.

So I built a tracker. It’s called HipPotion — same family as everything else I run here. The brewing turned out to be the easy part. Modeling it was where it got interesting.

Why a simple list doesn’t fit

My first instinct was “a batch is a row, log some notes.” That falls apart fast, because kombucha isn’t linear. It has two stages:

• F1 (first ferment): the big jar of sweet tea + SCOBY, fermenting sour over a week or two. One vessel, one culture.
• F2 (second ferment): you split that sour base into bottles and flavor each one differently — ginger in this one, blackberry in that one, hibiscus in the next — then seal them to build carbonation.

So one batch becomes many bottles, each with its own flavor, its own carbonation, its own outcome. A flat “batch = row” model can’t express that. And on top of the branching, every jar and bottle produces a stream of observations over time: pH today, Brix tomorrow, “tastes too sweet still” the day after.

That’s three different shapes at once — a lifecycle, a one-to-many split, and a time series — for what looks from the outside like “I made some tea.”

The model I landed on

Six tables, each earning its place:

• recipes — the templates. Tea blend, sugar ratio, target numbers. A batch points at one.
• batches — an actual F1 brew, with a lifecycle (planned → active → conditioning → finished) and a reference to its recipe.
• fermentation_log_entries — the time series. One row per observation per batch: pH, Brix, temperature, taste/smell notes, what I did. This is where the “pay attention and remember” lives.
• f2_variant_batches — the branch. Each is a flavored bottle split off a parent batch, tracked on its own.
• starter_log — SCOBY lineage. Cultures have parents; you grow new ones from old ones, and a sick culture ruins a batch, so the lineage matters.
• botanical_infusions — the flavoring ingredients, managed per recipe.

The shape that took the longest to get right was the F1 → F2 split: a variant has to belong to its parent batch but live its own life. Once that relationship was clean, the whole thing clicked — the app finally matched how brewing actually works instead of how it’s easy to store.

The stack (and where it runs)

Nothing exotic: React + Vite + TypeScript on the front (TanStack Query, shadcn/ui, Tailwind), a Hono + Drizzle ORM API on the back, PostgreSQL underneath. Built with AI coding tools — I leaned on them hard for the React/shadcn front-end, less so for the schema, which I argued out by hand because it’s the part that had to be right.

It runs on my k3s homelab like everything else: a Helm chart deploys the nginx frontend, the Hono API, and a Postgres StatefulSet, all reconciled by Argo CD from Git. Default-deny networking, secrets out of Git — the usual platform defaults. It’s a hobby app, but it gets treated like a real one, because the platform doesn’t know the difference and I don’t want it to.

It became an API for something else

The unexpected payoff: because the data model was clean and the API was just a set of plain REST endpoints, it made a perfect target for an experiment. I later pointed an AI agent at it from n8n — “what’s fermenting right now?”, “log that this batch tastes tart” — and the agent just called the same endpoints the UI does. A good schema is reusable in ways you don’t plan for. The kombucha tracker quietly became a little knowledge base I can talk to.

Honest notes

This is a personal hobby app for an audience of one (me). It’s AI-assisted, it has no tests, and the UI has rough edges. I’m not pretending it’s a product.

But the thing I keep coming back to: the hard, valuable part wasn’t the framework or the deployment — it was sitting with a messy real-world process long enough to find the shape of it. The branching ferment, the time series, the lineage. Get the model honest and the rest is just typing. Get it wrong and no amount of nice UI saves you.

Also, the kombucha’s been better since I started writing things down. Turns out the fridge wasn’t a great database.

I built Dice & Shrines with five asymmetric guardian characters. Each one has a different passive and active ability that changes how reinforcements distribute, which territories you can attack, and what happens when you take damage.

The question I couldn’t answer from just playing was: are they actually balanced?

Not “do they feel different” — they obviously do. But is Fox’s stored critical actually overpowered? Is Turtle’s loss-recovery passive strong enough to matter, or is it just flavour? Is there a first-mover advantage baked into the map structure?

You can’t answer questions like these from vibes. You need data. So I built a stats service.

What gets recorded

Every game produces five event types, posted as fire-and-forget HTTP calls from the game client to game-stats.hippotion.com/event:

map_generated — logged when the map generator accepts a map. Records territory count, average territory size, minimum size, and how many generation attempts it took. This tells me how often the generator discards its own work and whether the acceptance criteria are too strict.

game_start — fired when a game begins. Captures the number of players, the guardian assigned to each slot, and which slot is human. Returns a gameId that travels with the game for the rest of its life.

attack — fired on every single dice roll. Attacker, defender, from-territory, to-territory, how many dice each side had, what they rolled, who won. This is the raw material for the probability analysis.

elimination — fired when a player is knocked out. Records which guardian they were and how many players remained, so I can tell who exits first and who makes the final stand.

game_end — fired on win or abandon. Records the winner’s guardian, how many turns the game took, and whether it was abandoned.

The service is a FastAPI app backed by PostgreSQL, running in the homelab on the same k3s cluster as the game. About 150 lines of Python plus a schema.sql that the app runs on startup.

The dashboard

The stats dashboard is a single-page HTML response from / — self-contained, no external framework, chart.js for the visualisations. It polls /api/stats every 30 seconds and updates in place.

What it shows:

Overview cards: total games, games today, games this week, human win rate, average turns per game, overall attack win rate, abandoned game count.

Activity charts: games per day (last 7 days), game duration distribution in 10-turn buckets.

Death spiral analysis: when players abandon (broken into phases: instant, early, mid-early, mid, late), and first-mover advantage — win percentage by player slot 0 through 5.

Attack behaviour: the dice margin chart is the most interesting one. It shows attack volume and win rate for every possible attacker-dice-minus-defender-dice value, from strongly negative (attacker is outmatched) to strongly positive. Overlaid: a win rate line. You can see the actual probability curve emerging from real games and compare it to what the math predicts.

Guardian intelligence: win rate, pick count, average attacks per game, survival rate to turn 50+, and average turns per winning game — per guardian, human players only.

Elimination intelligence: when the first player gets knocked out per game, and a guardian fate table showing average elimination order and first-out percentage. Earliest-exiting guardian is surfaced explicitly.

Map influence: territory count versus average game length. Also an attack efficiency heatmap — win rate for every attacker-dice × defender-dice combination, 1 through 8, rendered as a colour grid.

Recent games: last 15 games with the human player’s guardian, result, and IP address so I can tell if it’s me testing or an actual player who wandered in.

What the data showed

The attack win rate across all games sits just under 60%. That’s higher than a naive analysis suggests it should be — if both sides roll fairly, equal dice should be near-even. The explanation is selection bias: players only attack when they have a dice advantage. Nobody sends 2 dice at 8 dice repeatedly. The average attack has a positive margin, so the average win rate is above 50%.

The margin chart made this explicit. The plurality of attacks have a margin of +2 or more. The sub-zero margin attacks — technically losing plays — are a real but small fraction, usually late-game desperation or deliberate tempo plays.

Human vs AI attack quality turned out to be the sharpest comparison. Humans and AI have different average margins. The AI is greedy but disciplined about attack selection; humans sometimes take gambles the AI wouldn’t. You can see it in the numbers.

First-mover advantage is measurable but not massive. Player slot 0 (goes first) has a slightly higher win rate than the average. Slots at the higher end of turn order are somewhat depressed. Not broken, but real — and a useful thing to watch if I ever add a competitive mode.

Guardian balance: the win rate gap between the best and worst guardian tells me whether the balance is within acceptable range or a concern. The dashboard calls it out explicitly: if the gap exceeds 15 percentage points, it flags it as a balance issue. That threshold is arbitrary, but it forces a decision rather than letting drift accumulate unnoticed.

Abandonment phases: most abandonments are instant — the player clicked “new game” before actually playing. The interesting number is mid-game abandonment, which is a proxy for death spirals: you see your income drop, you know you’re losing, you close the tab. That’s a design signal, not just a metric.

Designing for measurement

The useful insight from building this is that it changes how you design the game. Once you know every attack is being logged, you start thinking about what the attack data will tell you. Shrines give territories a guaranteed die — does that show up in attack margins near shrine territories? I didn’t add territory-topology tracking, but I could. The schema is just a few columns away.

The same goes for guardian abilities. Fox’s stored critical fires at turn boundaries — I log turn number on every attack, so I can look for Fox spikes in attack win rate on certain turns. I haven’t run that query yet, but the data is there if the balance question becomes sharp enough to need it.

That’s the thing about adding observability to something you built yourself: you stop guessing about whether it’s working and start reading the evidence. The game got more interesting to design once I could see what was actually happening inside it.

The stack

• FastAPI — event intake and stats API, ~150 lines
• PostgreSQL — five tables: maps, games, game_guardians, attacks, eliminations
• chart.js — dashboard visualisations, loaded from CDN
• k3s + Argo CD — deployed as a Kubernetes pod, Dockerised, managed GitOps alongside everything else on the homelab

Source at dice-n-shrines-stats.

I wanted to get a feel for AI-assisted coding tools — Claude Code, Codex — in a low-stakes environment where breaking things was fine. A browser game seemed like the right vehicle: self-contained, no prod database, no users to disappoint.

I picked a premise I knew was fun: Dice Wars. The Flash-era classic. Roll dice to attack adjacent territories, biggest army snowballs. Simple enough that I could focus on the tooling rather than the design. Or so I thought.

Six weeks later I had five asymmetric character classes, a procedural hex map generator with acceptance criteria, a FastAPI telemetry service recording every dice roll, and a stat dashboard I check more than I probably should. The tooling became a background concern. The game took over.

How the game works

The rules are genuinely minimal.

You start with a random slice of a procedurally generated map — a patchwork of irregular coloured territories, each one a cluster of hex tiles that reads as a solid blob. You and up to seven opponents begin scattered across it. Objective: own everything.

Attacking is one click. Select your territory, click an adjacent enemy territory. Both sides roll all their dice and sum. Higher total wins. Attacker wins: you capture the territory, your dice advance in minus one. Defender wins: your attack is repelled, you’re reduced to a single die on the attacking territory.

Reinforcements are the mechanic that makes this a strategy game. At the end of your turn, you receive bonus dice equal to the size of your largest contiguous group of territories. Not total territories — the biggest connected blob. Fragmented territory generates almost nothing. A solid connected bloc snowballs.

That one rule creates the entire strategic texture. Grab fast but stay connected. Chokepoints are worth defending at a loss. Cutting an opponent in half collapses their income immediately. The late game turns into tense standoffs until one roll cracks something open.

The shrines

Early on I added shrines — special territories marked with a ★. They behave differently from normal territories in a few ways:

• Higher dice cap: normal territories max out at 8 dice, shrines at 10
• Minimum floor: a shrine never drops below 2 dice after attacking, win or loss — it can’t be stripped bare
• Guaranteed reinforcement: the shrine gets a die first at end of turn, before random distribution
• Aura: each of your own territories adjacent to the shrine gets a +1 guaranteed die (shown with a dim ◆ indicator)

The shrine mechanic does something interesting to the risk calculus. Holding a shrine isn’t just a territory — it’s a node that warps the value of everything adjacent to it. You’ll defend an aura territory harder than a territory of equivalent size elsewhere on the map, because losing it means losing the aura bonus. It also means attacking into a shrine aura is expensive: the shrine can’t be worn down easily, and the neighboring territories keep refilling.

Shrines turned out to be the moment the math got interesting.

Five guardians

The game has a character select screen. Each player — human or AI — picks a guardian before the map generates. Five options, each with a passive and an active ability that meaningfully change how you play:

Hippo gets to manually place one reinforcement die each turn before the rest distribute randomly. One die placement doesn’t sound like much until you realise you always have a frontline territory that needs it more than anywhere else. High floor, consistent.

Hedgehog fills weakest territories first during reinforcement. Defensively solid — you never bleed out a border territory to zero while inland territories sit at cap. It doesn’t generate more dice, but it wastes fewer.

Fox banks a stored die every other turn and can spend it as a critical multiplier on an attack. The stored dice accumulate (up to a cap), so the power compounds if you resist using it. Two-hop flanking passive: Fox can attack across two territory hops from border territories, making it very hard to feel safely tucked away from.

Owl has a passive two-hop attack range like Fox but for all attacks — Owl sees further. The active ability is a Dice Transfer: move dice from one of your territories to an adjacent friendly one. Lets you concentrate force without committing to an attack.

Turtle gets 2 dice back to a neighboring territory any time it loses a defense. It’s the only guardian that turns taking damage into a resource. Hard to snowball, but very hard to finish off.

The AI cycles through the five guardians deterministically, so in a full 8-player game you’ll face at least one of each.

The map

The map generator produces irregular coloured territories from a hex grid. Hexes are the visual scaffolding — what matters in gameplay is the blob they form. Internal edges within a territory are hidden; only the outer border of each cluster is drawn. The result reads like a contested piece of ground rather than a grid.

The generator has acceptance criteria. A proposed map is rejected if territory sizes are too uneven — a tiny starting territory with 2 hexes versus a sprawling 15-hex territory produces a wildly unfair game. The stats service actually records generation attempts and acceptance rates per map, so I can see how often the map generator throws away its own work.

The mapId is stamped on every game record, so I can eventually correlate map topology with game outcomes. I haven’t done that analysis yet, but the data is there.

What the tools actually felt like

Claude Code handles the kind of work that benefits from holding a lot of context simultaneously: “this change to resolveAttack() in game.js needs corresponding updates to the AI logic in ai.js and the render pass in render.js.” That’s tedious to track manually and exactly the kind of thing where the tool earns its keep.

Codex was more useful for the boilerplate-heavy parts — filling in schema.sql, wiring up FastAPI endpoints, the chart.js setup in the dashboard. Directed generation of code you know exactly how should look.

Neither tool replaces thinking. The guardian ability design, the shrine balance, the question of whether Fox’s stored critical is too swingy in epic mode — that’s all still just sitting down and working it out. The tools speed up the translation from “I know what I want” to “here is working code.” The game design itself doesn’t compress.

It’s live

The game runs at dice.hippotion.com. Single HTML file served from a Kubernetes ConfigMap on my homelab. No accounts, no install. It runs fast — AI turns are instant when you toggle off animations, and a full game can be over in five minutes or stretch to twenty depending on how the map falls.

Stats dashboard at game-stats.hippotion.com. More on that in the next post.