FlazhAI.

context.

most flashcard tools make you write the cards. that's the part nobody does. the bet behind flazhai is that the deck should already exist by the time you decide to study — generated from something you were going to watch or read anyway.

the hard version of that promise is latency. "paste a youtube url and get a deck" only feels like magic if it happens before you lose interest. the whole architecture is bent around making cards appear on screen while the model is still writing them, not after.

the hard part.

youtube blocks anonymous transcript fetching from server ips and strips caption tracks on vercel. the fix is a three-layer fallback — db cache first (~30ms), then a paid residential-proxy fetch, then a second paid backup — so a missing transcript degrades instead of failing.

generation streams card-by-card: the model writes an array, each card is saved to postgres as it lands, and the client picks it up over server-sent events within ~250ms. inline dedup runs during the stream so duplicates never reach the deck, and the count is exact — ask for n, get n.

streamed, not awaited.

the spine is the vercel ai sdk streaming an array of cards while next.js writes each one to supabase the moment it's parsed. the client watches over sse and renders cards as they arrive. spaced repetition runs on a tuned sm-2 scheduler; near-duplicate cards are caught with pgvector embeddings. nothing about it is awaited end-to-end — the user watches the deck build itself.

what shipped.

youtube + document → deck generation, streamed live. sm-2 spaced review with smart daily queues, flip + mcq study modes, per-card ai chat / deepen / rephrase, anki .apkg import, public deck sharing, lemon-squeezy billing with purchasing-power pricing for indonesia, and full english + indonesian localisation. solo, end to end.