How to Add Personalized Flashcards to Your App (Copy-Paste Prompts Included)

Spaced repetition schedules each card based on how difficult it was last time. SM-2, the most widely used algorithm, adjusts two numbers per card: ease_factor (how easy the card is, default 2.5) and interval_days (how many days until the next review). After each rating (1=again, 2=hard, 3=good, 4=easy), the algorithm computes new values: new_ef = ease_factor + 0.1 - (5 - rating) * (0.08 + (5 - rating) * 0.02), clamped to a minimum of 1.3. The new interval is 1 day for 'again', or interval * ease_factor for 'good' and 'easy'. The card's next_due_date is set to today plus the new interval. Implement this as a pure JavaScript function and call it client-side after each card rating.

You need at minimum three tables: decks (id, user_id, title, is_public), cards (id, deck_id, front_content, back_content), and card_reviews (id, card_id, user_id, rating, ease_factor, interval_days, next_due_date). The card_reviews table is the one that grows fastest — at 10K users studying 50 cards per day, you're adding 500K rows daily. Add a composite index on (user_id, next_due_date) from the start; this index makes the study session query instant even at millions of rows.

Use CSS 3D transforms: give the card container perspective: 1000px and transform-style: preserve-3d. Create two child divs (front face and back face), both with backface-visibility: hidden. The back face starts at rotateY(180deg). On flip, apply rotateY(180deg) to the container — the front disappears and the back becomes visible. Toggle this with React state. The critical mistake is omitting transform-style: preserve-3d on the container, which causes the back face to never appear.

Query the card_reviews table for each card's most recent row per user. Cards with ease_factor > 2.5 and interval_days > 21 are a reasonable definition of 'mastered' — this matches roughly a month of successful recalls. Display the percentage of mastered cards per deck on the deck list. Avoid updating a 'mastered' boolean column on the cards table — the definition of mastery may change and recalculating from card_reviews is more accurate.

Yes. Add an is_public boolean to the decks table and set two Supabase RLS policies: one that allows all users (including anonymous) to SELECT decks where is_public = true, and one that allows the same for cards belonging to those public decks. The second policy is frequently missed — without it, anonymous visitors see the deck metadata but get zero cards in the study session.

Create a Supabase Edge Function that accepts a topic string and calls the Anthropic API (claude-haiku-4-5) with a prompt like 'Generate 20 flashcards about [topic]. Return JSON array of {front, back} objects.' Parse the response and return the array to the client. Show the generated cards in a staging review screen where the user can remove unwanted cards before importing them to a deck. At $0.08 per million input tokens, a 20-card generation run costs well under a cent.

The study session query should only fetch cards where next_due_date <= CURRENT_DATE (server UTC). Cards rated 'good' or 'easy' consistently will have next_due_date months in the future and simply won't appear. There is no need to mark cards as 'mastered' explicitly — SM-2 naturally removes them from daily rotation. If a user wants to force-study any card regardless of schedule, add a 'Browse mode' that fetches all cards in the deck without the due-date filter.

A 2-button system (know/don't know) is easier for users to understand and halves the interaction time per card. Use it for consumer apps and simple vocabulary study. A 4-button system (again/hard/good/easy) is the full SM-2 experience — it produces better long-term scheduling because 'hard' cards are delayed less than 'again' cards. Use it when your users are students studying for exams or certifications who will use the app intensively. The SM-2 formula requires a 4-point rating scale; with 2 buttons, map 'know' to rating=4 and 'don't know' to rating=1.