DEV Community: C W

I spent about a week and a half building a desktop app for Fooocus, then I panicked about the wrong thing.

C W — Tue, 18 Aug 2026 08:13:04 +0000

I spent about a week and a half building Fooocus Front, a Windows desktop app that installs, launches and drives Fooocus without a terminal, a console window or a setup guide.

Then someone told me about ComfyUI.

That annoying and sinking feeling is what this post is about, and if I'm being honest I still feel it as I'm writing this post. But having gone and checked properly, I'd say I probably have been worrying about the wrong thing.

What I built, briefly

Fooocus is excellent and deliberately minimal: one page, no sampler dropdowns, no CFG sliders. I'm a visual person and wanted something that feels like a place to make pictures, so I built one.

The interesting parts weren't the interface. They were a hidden launch (every Fooocus .bat ends in pause, which blocks forever with no console to press a key in, and Python block-buffers to a pipe so a quiet startup looks like it's frozen), a small Python bridge that runs inside Fooocus and puts jobs onto its own internal queue rather than scraping gradio, and an installer that sets up the right PyTorch build for whatever graphics card you own.

That last one taught me the most. The obvious way to check whether an Arc machine is already configured is to run python -c "import torch" and see if it works but it doesn't. Torch's Intel build needs a DLL search path the launcher sets up separately, so the probe fails on a perfectly healthy install. A check that reports a working setup as broken would trigger exactly the destructive reinstall it exists to prevent. It asks pip what's installed instead.

The release notes have the full feature list. This post is about what happened next.

The panic

"ComfyUI already exists" hit me about a day ago and it still stings. I built a UI. ComfyUI is a UI. Case closed.

Except when I actually checked:

ComfyUI is a node graph. I wanted something simpler than Fooocus's one-page form. ComfyUI goes in the opposite direction. Arguing I should have switched is arguing I should have solved a complexity problem by adopting more complexity.

Intel Arc is not a solved path there. I have an A770. Running ComfyUI on Arc means community install scripts or a third-party portable XPU build. Both are real options, both are maintained by people who aren't the ComfyUI team, and neither is "download and go."

SwarmUI is worse for my hardware. SwarmUI is the honest competitor, since it puts a friendly UI over a ComfyUI backend. But its maintainer's own answer in the Intel GPU discussion amounts to this: Swarm runs a stock ComfyUI as its backend, so install the IPEX prerequisites yourself and hope. Mine is verified on the card I own, and it generates from the moment the installer finishes.

So on the evidence, the week and a half I spent wasn't a duplicate. I'd like to say that settled it for me, but it hasn't quite yet.

The thing I should have been worried about

While writing this post I went and read the part of the Fooocus README I skipped like the fool I am.

Fooocus is in limited long-term support, bug fixes only, with no current plans to adopt newer model architectures. It's SDXL and it will stay SDXL. The README itself points people who want Flux towards WebUI Forge, ComfyUI or SwarmUI. The last release was v2.5.0, in 2024.

I built a careful installer, a repair system and a native interface for an engine that has stopped moving.

That's the actual critique, and nobody made it to me. The obvious objection, "ComfyUI exists," was wrong and easy to answer. The real one was sitting in the README I already opened.

There's a second one I found the same afternoon: my Intel Arc setup installs intel-extension-for-pytorch, which Intel retired at the end of March 2026 after upstreaming support into native PyTorch. My installer's headline feature is built on a package that's deprecated. Moving that path over to native PyTorch XPU is going into the next release.

Where that leaves it

Not in the bin. A few things survive the reckoning.

The deprecation is less dramatic than it sounds. The wheels still exist and still work, and Fooocus pins torch==2.1.0 anyway, which is exactly what my Arc branch installs. It isn't arbitrarily stale, it's matched to what Fooocus asks for. The migration also looks more tractable than I first assumed: RTX 50-series owners already run Fooocus on torch 2.7 and later to get Blackwell kernels, so the codebase tolerates a newer torch better than its pins suggest.

The bridge design matters more than I realised. Because it talks to Fooocus's internal queue rather than its web UI, retargeting it at a fork is a small change rather than a rewrite. Several forks exist, though check their commit history before trusting any of them; the one most often recommended hasn't shipped since 2024.

And SDXL being frozen isn't the same as SDXL being bad. It still makes good images, on hardware people already own.

The lesson, such as it is

"Check whether someone already built this" is not the useful question. Something has always already been built.

The useful question is whether the thing that exists solves your problem, and then, separately, whether the foundation you're building on is still moving. I got the first one right by accident and missed the second one completely.

If you're about to start something like this, don't be like me: read the project status section of the README before you write a line. It's usually two paragraphs, and it's usually the most important thing on the page.---

Fooocus Front v0.1.0-beta is out now. GPL-3.0, Windows only, unsigned installer, and Intel Arc is the only card it's been verified on. Every bit of the actual image generation is Fooocus, by lllyasviel and its contributors. They solved the hard part.

Puppergram: gram by gram, day by day.

C W — Sun, 16 Aug 2026 18:50:57 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

My dog just had ten puppies.

If you have never done this, here is the part nobody warns you about: newborn puppies all look identical, they cannot regulate their own temperature, and the only reliable sign that one is in trouble is that it stops gaining weight. Not the crying or looking thin, but Weight. A puppy that fails to gain for 24 hours is in serious trouble a day or more before anything is visible to you.

So you weigh them. Every day, all ten, and you write it in a notebook. And then at 2am on day five you are staring at a page of numbers trying to work out whether green is genuinely falling behind or whether you are just tired.

That is what I built. Puppergram is not a weight log with a calendar attached — it is an early-warning system. You record weights; it tells you which puppy needs attention tonight.

Seven hard-coded rules run over every weight you have entered:

Rule	Condition	Severity
Failure to gain	No weight increase in 24h	Warning
Weight loss	Any drop vs. previous entry	Warning
Below birth weight	Current < birth weight after 48h	Critical
Significant loss	More than 10% below peak weight	Critical
Slow doubling	Under 1.8× birth weight by day 10	Warning
Litter divergence	More than 25% below litter median on day N	Warning
Missing entry	No weight logged in 36h	Info

Nothing is inferred, predicted or modelled. The rule table is printed inside the app as well, because at 3am you are entitled to know exactly what set off the alarm.

Every alert carries an action, never just a label:

Green (Caeser) is 11% below its peak weight of 470 g.
Contact your vet today. Losses of this size in a neonate escalate quickly. Start supplemental feeding and check box temperature while you wait.

Demo

🐕 puppergram.pages.dev — press Load demo litter. You land on a six-day-old litter of seven with one puppy already in trouble, not an empty form.

🔍 puppergram.pages.dev/verify — the buyer's half. No wallet, no account, nothing installed.

Works offline once loaded, and installs as a PWA. The whelping box is in an outbuilding with no signal, so an app that needs a network is dead weight.

On a phone — the 3am screen:

On desktop — the whole litter at once:

Read green's row: +32 +30 +32 ±0 −2 −48. That stall is the entire product.

Code

chantleyw / puppergram

Gram by gram, day by day. Neonatal litter monitor for dog breeders: weight-led early warning from birth to eight weeks.

Puppergram

Gram by gram, day by day. A neonatal litter monitor for dog breeders — birth to eight weeks.

Puppergram watches every puppy's daily weight gain and tells you which one needs attention tonight, before there is anything to see.

Live: https://puppergram.pages.dev · Verify a passport: https://puppergram.pages.dev/verify

The problem

Neonatal mortality in dogs runs at roughly 10–30% in the first three weeks, and weight is the single most predictive vital sign — a puppy that fails to gain for 24 hours, or slips below its birth weight, is in serious trouble long before anything is visible. Most hobby breeders record weights in a paper notebook, where a stalling trend is invisible until it is a crisis. Puppergram is not a weight log with a calendar attached; it is an early-warning system, and the triage engine is the product.

How alerts work

Every rule is hard-coded, transparent, and applied only…

View on GitHub

git clone https://github.com/chantleyw/puppergram.git
cd puppergram && npm install
npm run dev

It runs with no API keys. Voice degrades to the browser's own recognition, and the keypad is always there.

How I Built It

React 18 + TypeScript + Vite + Tailwind, Dexie over IndexedDB, Recharts, deployed on Cloudflare Pages with Pages Functions. No accounts, no auth, no server-side database — everything lives on the device.

Nothing computed is ever stored

The whole app is one pure function:

buildLitterView(litter, puppies, weights, care, now) → LitterView

Weights in, everything out: day columns, daily gains, litter medians, alerts, milestone state, feeding volumes, temperature targets. There is no refresh button and no recalculate step because there is nothing to keep in sync. Log one weight by voice and the matrix, chart, alert banner, timeline and care cards all re-render from the same derivation.

Birth weight is not a stored field. It is the earliest weight entry. Store it separately and the two eventually disagree.

now is a parameter rather than a Date.now() call, which makes every time-window rule deterministic — and testable.

118 tests, because a false alarm is worse than no app

A false critical at 3am destroys trust in everything else the app says. So each threshold is tested in both directions — 10% below peak does not fire, 10.1% does — and there is a test asserting that a normally growing litter produces zero alerts.

Two pieces of deliberate restraint came out of writing those:

Below birth weight has a 48-hour grace window. Healthy newborns dip for the first day or two. Firing on that would train me to ignore the app by day three.
Litter divergence needs at least three weighed puppies. A median of two is just an average, and "below average" is not a finding.

Two features that came from using it on my own litter

I built this while the litter was already a week old, which surfaced things I would never have designed for:

Backlogging. I had a spreadsheet full of weights and had only typed in day 0 and day 9. The realistic case is not "I will enter each weight as I take it." So the weigh flow records against any day, with chips showing which days are complete, partial, or empty — the gaps are visible rather than remembered.

Eighteen collar colours. I had ten puppies and the app had exactly ten collars. Running out mid-whelp is a real failure, not a theoretical one.

The collar spine

Collar colour is the app's entire visual language. Every row carries a yarn-coloured spine; the chart draws each puppy's line in its literal collar colour; the weigh flow tints its header to whoever you are holding. The result is that the chart needs no legend anywhere — you already identify puppies by exactly this system, from the wool round their necks.

Prize Categories

🎙️ Best Use of ElevenLabs

You are holding a wet puppy in one hand and a kitchen scale in the other, in a dim shed, at 3am. Typing is the worst possible interface. Saying "blue, two forty five" is the best one.

ElevenLabs Scribe (scribe_v2) handles transcription through a Cloudflare Pages Function using a server-side key. There is no key entry field anywhere in the UI.

I use ElevenLabs for speech-to-text only, and that is a deliberate split. Transcription is where accuracy decides whether the feature works at all — mishearing "two forty five" as 240 writes a wrong weight into what is effectively a medical record, and that error propagates into every gain, median and alert downstream. That earns a real model. Reading a line back, though, is solved: every browser does it offline, instantly, free. A cloud readback would be silent exactly when the app is needed most. So ElevenLabs transcribes, and the device speaks.

Breeders do not talk like a form, so the parser handles what people actually say:

Spoken	Parsed
`blue two forty five`	245 g
`blue two hundred and forty five`	245 g
`blue two four five`	245 g
`blue one ten`	110 g

The interesting case is the elided hundred — "two forty five" means 245, so a single digit followed by a tens word becomes hundreds-plus-tens. It also copes with punctuation Scribe adds ("Blue, two forty-five" is a real transcript, now a test case), homophones (gray/grey, for/four), and refuses anything outside a plausible 50–20000 g range rather than recording it.

A parse is never committed automatically. It appears as a confirmation chip with one-tap Save, Correct or Discard. Voice you cannot correct is worse than typing.

Three layers, degrading silently: ElevenLabs → Web Speech API → the keypad, which is always on screen. Any non-200 means downgrade and continue. A voice feature that dies at 3am because a quota ran out would be worse than useless.

⛓️ Best Use of Solana

The problem: a buyer is handed a printed "health record" that anyone could have typed five minutes ago. There is no way to tell a real growth history from an invented one.

Puppergram already holds a timestamped, day-by-day record — exactly the artifact worth making tamper-evident.

I use Solana as a timestamping notary. No NFT is minted, and nothing but a hash goes on chain.

At handover the app builds a canonical passport (sorted keys, no whitespace, integers only, so the digest is reproducible byte-for-byte years later), takes its SHA-256, and writes one SPL Memo to devnet.

Here is a real sealed puppy — paste it into Solana Explorer with the cluster set to devnet:

jQbLD3m3zZQCGUtQ8hWfUujyRYqriLKrJcwdUPNuH137QXqZA3Lz7CMzeRs4TYxkzMjBFvC19b6ZMsK3BV5PdwK

The entire on-chain footprint:

Program log: Memo (len 71): "PGRAM1:13de6b0ceda53db495804660c51cddbfe47c2c915fa1b609739c0ff1c4ef423b"

A prefix and a hash. No name, no dam, no weights, no photo. Total cost: 0.00008 SOL.

The buyer's half needs nothing. They scan a QR that carries the whole passport — gzipped into the URL fragment, so it never even reaches my server — and /verify re-hashes it locally and compares against the chain. No wallet, no account, no app.

Both verdicts are confirmed on real hardware: sealing a puppy, scanning its QR with a phone, and getting ✓ Record verified — and editing a single gram produces a clear mismatch, with both fingerprints shown side by side.

Being straight about the limits: this proves a record has not been edited since sealing. It does not prove the weights were true in the first place. It is tamper-evidence, not truth — and it is on devnet, so it is a demonstration rather than a durable guarantee.

Puppergram is a breeder's record-keeping tool. It is not veterinary advice and not a health certificate. If something looks wrong, call your vet. I built it because I was doing this arithmetic on paper at 2am with ten puppies and a head torch, and a computer should have been doing it for me.

MIT licensed.

The Ghost in the Machine: Hunting a Memory Leak I Couldn't See the Source Of.

C W — Wed, 15 Jul 2026 08:09:42 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

Most bug stories start with a stack trace in your own code. This one starts with a stack trace in code I'd never seen, couldn't read, and wasn't allowed to touch — a closed-source, decades-old ERP that a critical overnight process depended on. No source, no debugger, and no PRs to link at the end of this post, because there was never any of my own code to change.

What I did have was a process that fell over in the small hours, a vendor whose only advice was to "call support," and a stubborn refusal to accept "it just does that sometimes" as an answer.

Here's how I smashed a bug I could only ever observe from the outside.

The symptom

Every night, an integration job that shuttled financial settlement data between two systems would throw this at me:

System.OutOfMemoryException
   at System.Text.Encoding.GetChars(Byte[] bytes, Int32 index, Int32 count)
   at System.Text.Encoding.Convert(...)
   at <VendorLib>.SQLSupport.Extensions.ToByteArray(String s)
   at <VendorLib>.SQLSupport.Helper.Serializer.ToDataBuffer(IEntity entity)
   at <VendorLib>.SQLSupport.ServiceProxy.ActivityServiceProxy.GetNextRecord(...)
   ...

OutOfMemoryException. On a server with tens of gigabytes of RAM. The recommended fix from the vendor? Just a phone number.

The errors clustered in a roughly 20-minute window in the early hours, and I'd learn later that interactive users were hitting the same wall during the day without anyone connecting the dots. The problem had apparently been shrugged at for a long time.

False trail #1: "It's corrupt data"

My first theory was a poisoned record. The stack trace dies while serialising a string into a byte buffer — ToByteArray reading some field's length and trying to allocate. A garbage length value would make it try to allocate gigabytes in one shot and throw instantly. That fit the "fails on a specific record" idea perfectly.

Except it didn't hold up. The errors pointed at multiple different datasets, on different internal methods, not one record in one place. When even a security/session-setup call throws OutOfMemory, you're not looking at one bad row — you're looking at a process that's already on its knees before it even gets to your data.

False trail #2: "The server's out of memory"

The obvious next thought: But here's the thing about a .NET OutOfMemoryException: it very often has nothing to do with physical RAM. It means the process couldn't get the memory it asked for — and a 32-bit process can only ever address about 2GB, no matter how much RAM the machine has. That ceiling is baked into the architecture, not the hardware.

So I opened Task Manager, found the long-lived process behind the failing component, and watched it.

140 MB.

The process throwing "out of memory" was sitting at 140 megabytes. The server had oceans of free RAM. This was never a RAM problem. It was an address space problem — or it would be, if something were filling that 2GB up. But at 140MB? Something didn't add up. Unless I was looking at the wrong moment in the cycle.

That's when I stopped guessing and started measuring.

The stakeout: teaching myself what the process did all day

I couldn't attach a profiler to vendor software in production. So I did the crude, reliable thing: a scheduled script that logged the process's committed memory, working set, and handle count once an hour, to a CSV. Keyed off the service account rather than the process ID, so it would re-find the right process automatically each day even across daily server restarts.

Then I waited a day and looked at the curve.

Time    CommitMB   Handles
10:00      293       2889
11:00      387       3779
12:00      485       4650
13:00      578       5596
...        ...        ...
21:00     1361      13429
22:00     1451      14361   <- flatlines here (users log off)
02:00     1456      14492
03:00      178       1781   <- reboot resets it

There it was. A dead-straight climb of ~96 MB every single hour, from a low baseline right up toward the ceiling — and then a hard reset overnight. A textbook memory leak, drawn in a perfectly clean line.

Two details made it click:

Handles rose in lockstep with memory — about 970 per hour, tracking the megabytes almost proportionally. Memory and handles leaking together is the fingerprint of unreleased references: every leaked object clings to both a chunk of memory and an OS handle. In an old reference-counted component, that's a missed release on a hot path.
The leak flatlined when people logged off at night. It was usage-driven — every operation leaked a little, so when the work stopped, the growth stopped. Not a background timer; a per-operation leak.

And the "why 02h00?" finally made sense. The leak built all day and by the wee hours the process was near its ceiling and its free space was fragmented. That's exactly when the overnight job attempted its single largest allocation — a big data pull. An already-exhausted, fragmented 2GB address space couldn't hand over one contiguous block that size, and bang — OutOfMemoryException. The daily reboot then wiped the slate, and the cycle began again, which is precisely why nobody had ever caught it in daylight.

The 140MB I'd seen earlier? I'd happened to look just after a reboot. The stakeout caught the whole story the snapshot couldn't.

Confirming the culprit

The process was a COM+ surrogate host. Its executable path gave away the last piece:

C:\WINDOWS\SysWOW64\dllhost.exe /Processid:{GUID}

SysWOW64 = 32-bit on 64-bit Windows (yes, the naming is backwards). Matching that GUID against the registered COM+ applications pinned it to one specific component — the vendor's data-access layer that every operation, interactive and batch, funnelled through. One leaking process, every code path. That's why the overnight job and the daytime users failed for the same reason.

Diagnosis complete:

A 32-bit COM+ component leaks memory and handles at ~96 MB/hr under load (unreleased references). Over a day it approaches the 2GB address-space ceiling; fragmentation plus the overnight job's large allocation tips it into OutOfMemory. The nightly reboot masks it.

So not RAM, or corrupt record. Just a reference leak meeting a 32-bit wall.

Smashing it (without a compiler)

I couldn't fix the leak since it's not my code. So the goal shifted from fix the bug to make the system resilient despite an unfixable dependency.

The component ran under COM+, and COM+ has a feature made for exactly this: application recycling. You can tell it to tear down and respawn the process when it crosses a memory threshold — automatically, mid-life, without a server reboot.

I set the memory limit to 1 GB (1048576 KB — a clean 1024×1024, comfortably below the 2GB wall with a full gigabyte of headroom so any large allocation still finds contiguous space):

COM+ application → Properties → Pooling and Recycling → Memory limit (KB) = 1048576

There was one nervous moment. The component's own logs kept saying hasrecycled=[False] while messages were in process — it refused to recycle while busy, and it was always busy. I braced for the fix to do nothing. But that flag was a per-instant status, not a permanent refusal: COM+ waits for a gap between operations and takes it. Under real load there were enough sub-second gaps, and it started recycling right at the 1GB mark.

Before and after

The same homemade logger that caught the bug proved the fix. Same CSV, different shape.

Before: memory climbs to ~1.45GB, address space fragments, overnight job fails almost nightly, users hit errors as the day wears on.

After: the process now cycles up and down — climbs to 1GB, recycles to baseline, climbs again — never approaching the ceiling. The tell-tale sign it was genuinely recycling and not just rebooting: the process ID changed mid-day, without a server restart, with memory dropping to baseline at that exact moment.

The overnight and daytime errors stopped. Days of clean logs, including busy days that used to be the worst offenders. Harmony restored — not by changing a line of the offending code, but by boxing it in so its worst habit could never reach the failure point.

The twist: the bug has a sibling

Here's the part that keeps it from being a tidy ending. A second environment runs its own independent copy of the same software — same component, same leak, its own separate install. Fixing one did nothing for the other. The same recycling mitigation now has to be replicated there. A leak in shared-but-copied software isn't one bug; it's one bug per copy.

What I'm proud of, and what I learned

Proud of: solving it with nothing but observation. No source, no profiler, no vendor cooperation — just a stack trace read carefully, a snapshot that lied, and a homemade logger that told the truth. The whole diagnosis came from treating a black box as knowable if you measure it patiently enough.

Learned:

OutOfMemoryException is a liar's name. It rarely means "the machine is out of RAM." Nine times out of ten it means a single process hit its own ceiling — and for 32-bit processes that ceiling is ~2GB no matter what the server has.
A single snapshot can send you the wrong way. 140MB "proved" it wasn't memory. Only the trend over time told the real story. Measure the curve, not the point.
Memory and handles rising together is a gift of a clue — it points straight at unreleased references rather than a runaway cache.
You don't always get to fix the bug but sometimes you fix the blast radius. Recycling didn't cure the leak; it made the leak unable to hurt anyone. For a dependency you can't change, resilience around it is a legitimate win.
A reboot that "fixes" something every night is a bug wearing a disguise. If a scheduled restart is load-bearing, there's an unsmashed bug hiding behind it.

The ghost is still in the machine — I never exorcised the leak itself. But it's in a box now, recycled back to harmless before it can ever reach the wall. Sometimes smashing a bug means making sure it can never land the hit.

Dōjō 道場 — karate made me do it.

C W — Sat, 11 Jul 2026 07:46:00 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

Dōjō (道場) is a Shito-Ryu based karate kata training companion, built around the Passion Edition prompt taken literally, to say that passion is the fire that drives us.

The home screen is a living flame that grows with your training, fed by both your streak and the effort you put in each day. If you show up consistently, it builds and feeds the flame; if you put in a hard session, it flares up that same day. It's a real canvas particle fire and not a static graphic.

The core is a count-along kata drill with a live sensei voice. Pick a kata, set the tempo, and a sensei counts you through it in Japanese — ichi, ni, san… — on the beat, with a kiai shout on the traditional counts and an optional metronome. Pause/resume mid-drill, and every kata's counts are editable, since those conventions vary by branch. Finishing a drill logs the session and feeds the flame.

Rounding it out: a kata hall grouped by their respective lineage (Pinan, Shuri-te, Naha-te), with a belt-and-history view, and a one-tap Kiai button to test the chosen voice.

I have been practicing karate for 30 years and my goal was to build something that feels like stepping into a dōjō, not opening a fitness dashboard — and to make the voice feel like a real sensei counting beside you.

Demo

Code

chantleyw / dojo

Dōjō · 道場

A Shito-Ryu (糸東流) training companion with a live sensei voice.

Dōjō is a karate practice app built around a single emotional idea: passion is the fire that drives us. The home screen shows a flame that grows with your training streak — a cold ember at zero, a roaring fire past 30 days. Pick a kata and a sensei voice counts you through it in Japanese, on the beat — ichi, ni, san… — with a kiai shout on the traditional counts and an optional metronome tick.

Built for the DEV.to Weekend Challenge (Passion Edition).

✨ Highlights

A flame that grows with your streak. Layered SVG plume with a Framer Motion flicker, driven by fire = min(1, streak / 30). Reduced-motion holds it still.
A live count-along drill. Choose a kata; the sensei counts in Japanese on the beat, kiai-ing on the traditional counts. Tempo…

View on GitHub

How I Built It

The stack is Vite + React + TypeScript + Tailwind, with Framer Motion, Zustand for state, the Web Audio API for the metronome, and Netlify Functions for the backend. State persists per-device in localStorage — so no accounts are required.

The sensei voice (ElevenLabs)
This is the core of the app, and getting it to feel live drove most of the interesting decisions.

A custom voice, built in Voice Design. The sensei is a purpose-built deep, gravelly grand-master voice created in ElevenLabs Voice Design — the kind of voice that could bark a battle command. The app pulls every voice on the account into a picker, but defaults to the sensei.

Authentic Japanese counting. Numerals are generated programmatically as hiragana (いち, に, さん…, composing じゅういち for 11, and so on) and spoken with Turbo v2.5 using language_code: "ja". That language flag was the unlock because without it, an English-leaning accented voice pronounces さん like the English word "san"; with it, you get a proper sahn pronunciation.

Making it land on the beat. A count drill can't afford a network round-trip per number. So on "Begin," the app pre-generates one clip per unique word, caches them as object URLs keyed by text, then plays the cached audio on each metronome beat. The count and the kiai are also given separate expressiveness profiles — the counts stay crisp and consistent, while the kiai runs at low stability / high style for a raw, shouted delivery.

Keeping the key safe. The link is public, so the ElevenLabs key can never touches the browser. A tiny Netlify Function proxies /api/tts and /api/voices, holding the key in an env var and forwarding requests server-side. The client only ever talks to my own domain.

Never hard-failing. If the proxy returns a non-200 — a quota cap, a rate limit — the app falls back to the browser's built-in speech synthesis (preferring a Japanese voice) and keeps counting. I actually hit this live during testing when a capped key ran dry, and the drill kept running on the fallback voice without a hiccup. Generation is also concurrency-limited with retries so the free tier's request limits don't drop individual clips.

The flame is a canvas particle system — rising flame particles, floating embers, and an additive glow, all scaling with a single fire value from 0 to 1. Rather than tie that purely to the streak, I compute it from both consistency and effort: fire = 0.7 × (streak / 30) + 0.4 × (today's minutes / 45), capped at 1. A long streak carries a strong baseline, a hard session flares it up the same day, and a single huge day can't max it out alone. Reduced-motion users get a still flame instead.

Prize Categories

Best Use of ElevenLabs. The sensei voice is the core of the app: a custom generated Voice Design grand-master voice, spoken with Turbo v2.5 and language_code: "ja" for authentic Japanese counting, pre-generated and cached per word so it lands on the beat, with separate expressiveness profiles for the counts and the kiai which are all served through a serverless proxy that keeps the API key off of the client, with a seamless fallback to the browser voice so a public link never hard-fails.