Should I vibe code
Import permitted text and audio, mark known words, and review vocabulary in context
The reader is a weekend. Three years of known-word statuses in a database you never backed up is the product.
?
Their verdict, the Premium price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A reader that tokenises a text, colours each word by how well you know it, and lets you click one to look it up is a very good weekend, and for a language written with spaces it is genuinely competitive with the paid thing. Nothing here touches anyone else: no accounts, no strangers, no money, no regulator. Two honest caveats. The first is that your known-word database is the entire asset and it is unrecoverable — three years of clicking is not something you rebuild, so it needs a backup story on day one rather than after the incident. The second is that what LingQ actually sells is not the reader, it is a library of lessons with matched audio and an app that works on the bus. If those are what you wanted, no amount of code produces them.
What actually breaks
not "if". the specific failures.
- Tokenisation, which is a regex for Spanish and a research problem for Japanese, Chinese and Thai, where nothing tells you where one word ends
- Lemmatisation, so "went" never counts as "go", every Russian case is a separate unknown word, and a German separable verb is two words that are neither
- The known-word database itself — the one thing in the project you cannot regenerate, sitting in a SQLite file inside an app directory your backups skip
- Dictionary lookups, where a free API becomes a paid one, a rate limit appears mid-session, or the offline dictionary you shipped has a licence you did not read
- Audio-to-text alignment, which is what makes reading along work and is the difference between a demo and something you use daily
- Sync, because the reading happens on a phone on a commute and the word statuses live on your laptop
Is that you?
the verdict is a default, not a law
- It is your own reading, on your own machine, over texts you already have the right to read
- The word-status store is a plain file you back up, and there is an export button before there is a second feature
- Your target language uses spaces, which removes the single hardest problem in the build
- You would be happy with it as a laptop-only tool and are not quietly expecting a mobile app
- You are planning to host imported books or transcripts for other people to read
- The known-word data lives only inside the app and there is no export
- You are learning Japanese or Chinese and have not looked at what segmentation actually costs
- You are calling a paid translation API on every word hover with no cache and no budget
If you build it anyway
the checklist, then the prompt that enforces it
- Word statuses are the asset. Store them in a plain SQLite file or a JSONL you can read with grep, back it up on a schedule, and write the export before anything else.
- Export in a shape something else can import — word, language, status, context sentence. Lute and Anki both take a TSV, which is your entire escape hatch.
- Use an existing segmenter for your language rather than writing one: MeCab or SudachiPy for Japanese, jieba for Chinese, spaCy or simplemma for European languages.
- Decide early whether status attaches to the surface form or the lemma, and record both. Changing your mind later is a migration over the only irreplaceable table you have.
- Cache every dictionary and translation lookup on disk, keyed by word and language, and cap the daily spend. A hover handler with no cache is a bill.
- Keep imported texts as files in a folder with their source noted. Your own library is personal use; a hosted copy of somebody's book is a different conversation.
I am building a personal reading tool for language learning: import a text, tokenise it, track how well I know each word, look words up in place. The only thing here I cannot rebuild is the word-status history, so treat it as the crown jewels and order the work around it. 1. Before any UI, define the word-status store and its export. Plain SQLite or JSONL, one row per term with language, status, timestamp and an example sentence. Show me a working TSV export that Lute or Anki could import. 2. Add a scheduled local backup with retention, and show me how to restore it with the app not running. Three years of clicks is not recoverable from a screenshot. 3. Every schema change to that store runs on a copy first and keeps the previous file. This is the one migration I cannot survive getting wrong. 4. Ask me which languages I actually read, then use an existing segmenter for each — MeCab or SudachiPy for Japanese, jieba for Chinese, spaCy or simplemma elsewhere. Do not write a tokeniser, and if my language has no spaces, tell me plainly that this is the hard part of the whole project. 5. Decide with me whether status attaches to the surface form or the lemma, record both from the start, and explain the trade-off before writing it. 6. Cache every dictionary and translation call on disk, keyed by term and language, and enforce a daily request cap. No uncached call from a hover handler. 7. Imported texts stay as files in a folder with their source recorded. Do not build sharing, a public library, or anything that redistributes text I imported. 8. Reading state — position, current lesson, audio offset — is separate from word status, so losing one does not corrupt the other. 9. Out of scope, and say so rather than half-building it: accounts, sync, mobile apps and a content library. Those are what the subscription is for.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
If what you wanted was the library rather than the reader. LingQ's catalogue of lessons with matched audio and transcripts is licensed content, and the mobile app is where the reading actually happens for most people — neither is something you can write. At $14.99 a month, or $10 on the annual term, that is the honest thing you are buying. The reader over your own texts is worth building regardless.
$14.99/mo is cheaper than your weekend.
One TSV of terms, statuses and example sentences, exported on a schedule. That single file is the entire value of the project and it imports into Lute, Anki or a spreadsheet, which means walking away costs you the reader and not the years. Keep imported texts as ordinary files in a folder for the same reason.
Actively maintained open-source LingQ-alike: import texts, track word status, review in context.
The spaced-repetition half, solved for twenty years, with an import format worth exporting to.
Questions
Why is this SHIP IT when canivibecodeit only said KINDA?
Because we are answering a different question. They are judging whether an agent can build the whole product, and the whole product includes a content library and mobile apps. We are judging whether you will regret shipping it — and a single-user reader over your own texts, with an export button, has no blast radius at all. Build the reader, do not expect the library.
Is Lute not just this, already built?
Largely, yes, and that is the most useful thing on this page. Lute is actively maintained, runs locally, and already handles the segmentation and word-status model that will eat your first two weekends. Build your own if the building is the point; install Lute if the reading is.
What actually goes wrong if I skip the backup?
Nothing, for about eighteen months. Then a schema change, a bad migration or a laptop reinstall takes the file, and there is no way to reconstruct which of forty thousand words you had marked as known — the data was never anywhere else and it only existed as a side effect of you reading. It is the one irreversible thing in an otherwise entirely reversible project.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice