Building an Anki inspired math and reading practice app

Sun, 13 Sep 2026 08:20:06 +0000

At a glance


Problem	Turn an Anki-inspired study method into a focused product that parents could use with children for daily math and reading practice
Scope	Product architecture, adaptive scheduling, study queues, reusable card content, learner profiles, phone authentication, localization, and deployment
Result	A free production Rails application with math and reading decks, adaptive review intervals, phonics support, and an English/Spanish interface
Delivery	Core product engineering for Learn To Be, from the initial data model through launch and production fixes

The problem

Learn To Be wanted a focused product that parents could use with children for daily math and reading practice. The intended routine was deliberately small: choose a deck, ask the learner to recall an answer, reveal it, rate the response, and return when the right cards are due again.

The product uses spaced repetition, a study method that brings material back for review at increasing intervals as it becomes easier to remember. Its scheduler is based on the Free Spaced Repetition Scheduler (FSRS), an open-source algorithm that uses the learner’s recall ratings to estimate memory strength and decide when each card should return.

The simple interface concealed several connected engineering problems. The application needed to decide when every card should return, mix cards at different stages without losing or duplicating them, keep each child’s progress separate, and support very different material—from multiplication facts to words with audio and phoneme breakdowns. It also needed to remain practical on a phone and understandable in both English and Spanish.

I built the core application in Rails 8 and carried it through to the production service at ltb.cards.

What I built

Implemented adaptive scheduling with FSRS

The scheduler is an in-application Ruby implementation of the Free Spaced Repetition Scheduler (FSRS). Instead of giving every learner a fixed sequence of delays, it maintains a memory model for each card using:

retrievability, the estimated likelihood that the learner can recall the card now;
stability, how long that memory is expected to remain retrievable; and
difficulty, which changes in response to the learner’s ratings.

After the answer is revealed, the interface shows four choices—Again, Hard, Good, and Easy—and previews the interval produced by each one. A response updates the card’s memory state and calculates its next due date. The default target retention is 90%, intervals are bounded between one day and 36,500 days after graduation, and longer intervals receive a small amount of fuzzing so many cards do not repeatedly become due together.

The implementation treats a card as a state machine rather than only a date. New material moves through one- and ten-minute learning steps before graduating to review. A failed mature card enters a ten-minute relearning step, while its stability and difficulty are updated from the FSRS formulas. This made short-term practice and long-term scheduling part of one explicit model.

Every response is also stored as a review event with its rating, timestamp, resulting interval, resulting difficulty value, and time taken. That leaves an audit trail for understanding the scheduler’s decisions and makes future analysis possible.

Made the queue a single source of truth

Scheduling a date is only half of a study system. The application also has to choose the next card correctly.

I separated queue construction from card selection. CardQueueService defines the database relations for new, learning, review, and relearning cards; both the next-card selector and the on-screen counters use those same relations. This change removed an earlier class of bugs where the displayed counts and the actual study sequence could disagree.

The selector prioritizes learning cards that are due now, then mature reviews, relearning cards, and the day’s new material. When no other work remains, it can bring forward a learning card due within the next 20 minutes. Daily new-card limits prevent a learner from taking on too much material at once, and all day boundaries are calculated in the learner’s own timezone.

A particularly subtle product rule was when to create progress. A card schedule is created only when its answer is revealed, not merely when its question is displayed. Reloading or leaving an unseen card therefore does not consume the learner’s daily allowance or incorrectly mark the card as started.

Designed content that could grow beyond flashcard text

I used a note-based model inspired by Anki, separating content from presentation:

a note type defines fields and one or more templates;
a note stores the field values in PostgreSQL JSONB; and
one or more cards select templates from that note.

One vocabulary note can therefore produce recognition and production cards without duplicating its source content. The same model handles arithmetic, formulas, words, explanations, images, and audio.

Templates use {{field_name}} placeholders and allow a controlled subset of HTML and Tailwind classes. The rendering component substitutes values, applies consistent defaults, expands approved custom elements, and sanitizes the result. Media stored in S3 receives a short-lived signed URL, with generated URLs cached to avoid repeating that work on every render.

For reading decks, I added a custom <word-breakdown> element. It looks up a word in the Carnegie Mellon Pronouncing Dictionary and maps its phonemes back to visible grapheme groups using a set of position- and context-aware rules. A word can then be presented as the letter groups and sounds a learner should practise, including common multi-letter sounds and silent letters. Normal- and slow-speed audio can sit alongside the same card.

Kept the learner experience focused

A single account can contain multiple learner profiles, each with independent deck choices, schedules, review history, daily limits, and timezone. Passwordless phone authentication keeps sign-in concise, while an administrative data portal supports the client’s operational work.

The interface is responsive and uses Turbo for the answer reveal, so the question can transition into feedback without turning the study flow into a client-side application. The complete learner-facing experience is localized in English and Spanish.

Result

The result is a deployed learning product rather than a scheduling prototype. LTB Cards combines the algorithm, queue semantics, reusable content system, authentication, profiles, localization, administration, and production infrastructure required to run daily study sessions.

The architecture also gave Learn To Be room to expand the curriculum without rebuilding the study engine. Deck-generation tasks produce multiple levels of addition, subtraction, multiplication, division, and reading practice. New card formats can be introduced through templates, while specialized teaching interactions can be added as controlled custom components.

The most important outcome was preserving a simple product surface over a non-trivial domain model. A parent sees one card and four clear choices; behind that interaction, the application records the attempt, updates the learner’s memory model, chooses a future interval, maintains daily limits, and places the card into the correct queue.

Validation and iteration

The FSRS specification covers defaults, custom scheduler options, each transition between learning, review, and relearning, retrievability, and minimum and maximum intervals. Model specs cover schedules, decks, profiles, notes, note types, and review records. Queue behavior received dedicated regression coverage for due cards and learn-ahead boundaries.

Production iteration exposed the cases that are easy to miss in a first implementation: queue counters diverging from selection logic, new cards being consumed after a reload, incorrect timezone use, daily statistics failing to reset at midnight, and relearning behavior after a lapse. I addressed these as explicit domain rules rather than view-level patches, culminating in the shared queue service used by both selection and reporting.

The application remains live at ltb.cards.

Product Development on Haseeb Annadamban