Vibecode build plans · № 7

Build a flashcards app

Flip a card, grade yourself, come back to the ones you miss — one file, your decks, spaced repetition that actually schedules.

Flashcards are a great vibecode because the hard part isn't the UI — a card that flips is fifteen minutes of work. The hard part is the logic that decides what you see next, and that's exactly where a coding agent, left to its own devices, will quietly cheat you. This plan makes it do the real thing.

You already know how this ends if you use a rented flashcard app: a login, a paywall on a second deck, a "streak" designed to farm your guilt. Cut all of it. A study tool is a text file plus a scheduler. It fits in one HTML file, it lives in your browser's localStorage, and it is yours — no account, no sync, no one grading you but you.

The spec — and the cuts

• One HTML file. Inline CSS and JS, no build step, no framework, under 50KB. A study tool does not need a bundler.
• Decks live in localStorage. You type or paste cards, they persist across reloads, and every edit saves immediately. No server, no account, no sync — the browser is the database.
• The card is the unit. A front, a back, and a box number. Flip to reveal, then self-grade "got it" or "missed" — that grade is the only input the scheduler needs.
• Cut: accounts and cloud decks. If two devices need the same deck, that's an export button someday, not a backend today.
• Cut: images and audio on cards. Text fronts and backs only. The moment you inline media you've tripled the file and reinvented Anki.
• Cut: a full SM-2 algorithm with ease factors and intervals in days. Leitner boxes give you 90% of spaced repetition with none of the floating-point ceremony. Five boxes is enough.

The prompts

Tick the features you want — the prompts below rewrite themselves. Then paste them into Claude Code (or Cursor, or any agent) one at a time, in order.

Where agents go wrong on this build

• Losing your decks. The classic failure is holding cards in a JS array and only writing to localStorage "on save" — so a reload after a quick edit eats your work. Persist on every mutation, and wrap the write in a try/catch: localStorage has a quota, and a silent QuotaExceeded error looks exactly like "my deck vanished."
• A parse failure that wipes the deck. Paste import is where this bites: one malformed line — a card with no |, an empty row — and a naive parser throws, or worse, overwrites a good deck with a half-parsed one. Validate first, import into a fresh array, and never replace the stored deck until the whole paste parsed clean.
• Fake spaced repetition. This is the one that matters. "Got it" must promote the card one box; "missed" must reset it to box 1; and the scheduler must actually surface low-box cards more often. If every card comes up equally regardless of box, you've built a round-robin wearing a spaced-repetition costume — it looks right and teaches nothing. Prompt 2 is entirely about not letting the agent ship that.
• Rendering card text with innerHTML. Your cards are user text, and the second a card contains <img onerror> or a stray angle bracket, innerHTML either breaks the layout or runs it. Use textContent everywhere a card is displayed. It's one word and it closes the whole hole.

Why the feedback step is in the plan

You are the worst possible tester of your own flashcards app, because you know what every button does and you wrote the cards. You can't feel the moment a first user flips a card and doesn't realize they're supposed to grade themselves, or hits a dead end after the last card with no idea what "box 3" meant. Prompt 4 wires your agent to our MCP server: it shares the live page, you send the link to one or two people, they tap and pin notes right on it (no login), and your agent reads the notes back and applies what survives your judgment — anchored to the exact thing they pointed at. The loop that built this very page.