The most interesting thing in this batch of shipped side projects isn't any single feature. It's a posture. A developer posts a language trainer that runs without an account, keeps every byte of learner data in the browser with open import/export, and refuses to guess where it can't. A stock-direction toy in the same set brags that it "reads public daily bars, and errors out instead of inventing numbers." A YouTube-to-text reader, an emoji manager, a spaced-repetition English tool — all small, all single-purpose, all built by one person who wanted the thing to exist and then handed over the internals.
That's the signal worth acting on: builders are shipping honest, narrow, data-owned tools where the logic is legible and the user keeps the state. The FSRS English trainer is the sharpest example, so I rebuilt its skeleton on VicroCode to see how cleanly the pieces separate. Here's the debrief.
What the original actually does
The learning loop in that post is specific: forced blind-listening (audio plays, the sentence is blurred so your brain commits to the sound), then active typed input, then an explanation you unlock only after you've tried, then a short retrieval test, then progress stats, then spaced repetition driven by how the test went. The author deliberately skipped speech recognition — didn't want to be an "accent cop," and found the recognition threshold hard to tune. All user data lives on the front end with a JS interface to import and export.
What makes this reproducible is the seam between three concerns that people usually smear together: the scheduling math, the durable review state, and the practice UI. If you keep those apart, you can rebuild each one with a different tool and swap them independently.
The FSRS math is just a hosted computation
FSRS is an interval-scheduling algorithm. Given a card's current memory state and your grade on the latest review — say again / hard / good / easy — it returns updated stability and difficulty and the next due date. That's a pure function. It takes numbers in and gives numbers out, and it doesn't care what the UI looks like.
So I treated it as a backend I could run Python online: a small module that accepts a card's prior state plus a grade and returns the next-due timestamp and updated parameters. Keeping the scheduler server-side has a nice side effect — the interval logic isn't buried in front-end JavaScript where every learner can accidentally fork a different version of "correct." One implementation, one place to fix a rounding bug.
A practical friction worth naming: FSRS has default parameters, but its real strength is fitting parameters to a learner's own review history. Batch re-fitting over a growing log is heavier than a single card update, so I split it — cheap per-review updates on the hot path, an occasional heavier fit as a separate call. On a lightweight hosted runtime you want that separation before your log gets big, not after.
The review ledger is where ownership lives
The original keeps data on the front end. That's one valid answer to "who owns the state," but it's fragile — clear the browser, lose the history. I went the other direction and made the review history a database the learner can inspect and export, which is the same spirit with a sturdier floor.
Each card gets a row: the sentence id, current stability and difficulty, last reviewed, next due, and the full grade history. Because this is an SQLite editor rather than an opaque store, the state is genuinely legible — you can open the table, read why a card is scheduled for Thursday, correct a mistimed entry by hand, or dump the whole thing to hand to an agent later. That last part matters: the original author explicitly wants learning data to stay usable in an "agent era," and a plain, queryable table is far friendlier to that than a proprietary blob.
The trade-off with a single-file database is concurrency. For one learner practicing 1–2 hours a day this is a non-issue; writes are serial and tiny. If you ever fan this out to many simultaneous writers, the honest move is to reassess rather than pretend SQLite is something it isn't.
The practice loop is a hosted page
The blind-listen interaction — blur the sentence, capture the typed attempt, reveal the text, unlock the explanation, fire the test, send the grade back to the scheduler — is a self-contained front end. I built it as an app I could run HTML online, with the page calling the Python scheduler on each grade and reading due cards from the ledger. Keyboard-first, no reordering games, no login wall, which keeps the "serious tool, opens and works" feel the original was after.
One detail I kept: unlock the explanation only after an attempt. It's a UI rule, not an algorithm, but it enforces the retrieval-practice discipline the whole design rests on. Easy to skip, easy to regret skipping.
Where the platform boundary actually is
Two pieces of the original vision do not map onto the confirmed capabilities, and pretending otherwise would just set up a broken build.
First, audio delivery. Forced blind-listening needs audio to reach the learner's ears, and serving or streaming media files is outside what I can claim here. In this rebuild the practice page would reference audio hosted elsewhere; the platform holds the scheduling, the ledger, and the interaction shell, not an audio pipeline.
Second, speech recognition. The original author skipped it on purpose, so I didn't miss it — but it's worth stating plainly that in-browser or server-side ASR isn't part of this stack. The typed-input design sidesteps the whole question, which turns out to be a feature, not a compromise.
What a builder can take from this
The reproducible move isn't "clone a language app." It's the decomposition: scheduling math as a hosted pure function, durable state as an editable database the user owns, interaction as a thin hosted page, and a clear line drawn around the parts the platform doesn't cover. That shape fits far more than flashcards — habit trackers, drill tools, anything with a state machine and a nudge.
I have not measured retention or learning outcomes for this rebuild, and the original's cognitive-science framing is the author's own reasoning, not a validated result — treat both as unverified. What I can say is that the three-way split held up cleanly, each piece stayed swappable, and the learner's history stayed readable the entire time. For a solo builder, that legibility is the whole point.