1The problem
Many professionals already understand a lot of English — they read articles, watch talks, follow their field in the language every day. What holds them back isn't grammar: it's producing the right words at the right moment, in a meeting, an email or a job application. The vocabulary they need is specific to their work, and generic English courses rarely cover it.
There's a second trap: consuming content in English feels like studying, but it isn't enough. Reading a lot builds recognition, not the ability to use the words yourself. We wanted an app that turns that daily consumption into a real, usable repertoire — words you can actually produce, not just recognize.
2The stack
A product's is the set of software pieces that hold it up. We'll walk through IdLingo's and, more importantly, why we chose each piece — the decisions matter more than the names.
The whole app is written in : the screen, the behind-the-scenes logic and even the description of the cloud infrastructure all use the same language. Why? Because one language across the whole project means the pieces share definitions and catch each other's mistakes before anything runs. TypeScript is, in plain terms, a stricter version of JavaScript that warns you about errors ahead of time instead of letting them blow up live.
It runs on a setup in the cloud: there are no servers to keep on day and night, the code runs on demand and the capacity shrinks to almost nothing when idle, so the cost follows real usage. That comes with a catch, though — and the diagram below shows the fix we chose.
Serverless code can spin up many copies of itself at once, and each copy wanting its own database connection can exhaust the limit the database allows. The shares a small set of connections among all those copies, so the database never gets overwhelmed.
For storage we chose a (Aurora Serverless v2, running PostgreSQL) over a key-value one. A relational database is a set of tables that reference each other — picture the sheets of a spreadsheet workbook, linked by IDs. We chose it because our data is a web of relationships (people connect to the words they know, words connect to the materials they came from, and to a trail of learning events). The product is still being validated, so new questions of the data appear every week; in a relational database those queries — grouping, ranking, finding what's due for review — are trivial, while a key-value store would force us to know every access pattern up front and make changes painful. Aurora Serverless v2 keeps the serverless cost advantage, scaling down when nobody is practicing.
On top of that base, two more pieces complete the experience: an AI layer that generates examples and evaluates practice, and a voice service that reads any word out loud with , so there's no need to record a human voice for every term. Picking well-established cloud building blocks let us spend our own effort on what is actually new: the learning logic.
3How we used AI
The AI works in the background, not as a chatbot you talk to. When you register a link you read or watched, reads that content and pulls out the vocabulary that matters — single words and also the word combinations that sound natural together. Your repertoire updates from what you actually consumed.
During practice, the AI generates example sentences on demand and evaluates when you try to use a word in a sentence of your own — the hardest and most valuable step. Importantly, the app stays fully usable without AI: the AI-powered rounds are a bonus layer on top, never a wall in front of the basic practice.
Where does the AI come from? By default, from , using a platform credential — so the AI is simply available, with no setup from the user. Whoever wants more control can plug in their own key () from a provider like OpenAI, Anthropic or Google. The gate for an AI-powered feature is just "is AI available?", not a credit balance — the old credits model was retired.
4Key decisions
Learn from what you already consume. Instead of handing out a fixed word list, the app starts from the articles, videos and podcasts the person already follows. The reasoning: vocabulary sticks when it's relevant to your real life. Content you chose yourself is already meaningful — we just turn it into deliberate study.
Recuperar antes de reconhecer. <strong>Recall over recognition.</strong> It would be easier to build a flashcard app where you just flip and say "I knew that". We chose the harder path and organized the whole app around active recall and spaced repetition, bringing each word back right before you'd forget it. It's less comfortable, and it's what actually works.
Medir o conhecimento em graus, não em sim/não. <strong>Track knowledge in degrees, not yes/no.</strong> "Learned" isn't a switch — you can recognize a word today and fail to produce it next week. So we track each word by degree, and the diagram further down shows the seven states we use.
AI available by default, with the option to bring your own key. The AI comes on by default, so anyone can use the app with zero setup. For those who want control, there's the option to . And gamification rewards learning, not volume: you earn points for practicing and recalling, never for passively consuming content.
5Getting more technical…
This section is for whoever wants to look under the hood. None of it is required to understand the product — but these are the decisions that made the learning logic reliable.
The data model, in plain terms. A few tables carry the whole product. One holds the people; one holds each person's profile; one holds the catalog of words and expressions; one connects a person to a word and records how well they know it — moving through seven knowledge states (see the diagram). A final table keeps a log of learning events: every bit of evidence of practice, in the order it happened. The state table answers "how well does this person know this word now?"; the events table is the trail of "how did we get here?".
Unknown — no evidence yet that the person has met the word.
Exposed — the person has already come across the word.
Recognized — recognizes the form or meaning when shown it.
Recalled — retrieves the word with little or no help.
Produced — produces the word in a controlled task.
Used — uses it appropriately in real communication.
Stable — consistent over time, after spaced practice.
Why custom tables and foreign keys. The relationships are enforced on purpose: there's exactly one state per person-and-word pair, so a word can't accidentally hold two conflicting states. The link between tables is a — a column in one table that points to a row in another, which is exactly what makes the database "relational". The learning-events table is append-only: we never edit the past, we add a new event, and that new evidence is what updates the current state.
Idempotency, so nothing counts twice. means making an operation safe to repeat: run it once or five times, the result is the same. It's what protects us when the delivers the same task twice — the diagram just above shows where it fits.
Polling and an asynchronous pipeline. is when the app repeatedly asks "is it ready yet?". We use it for speaking practice: you upload your audio, then the app polls for the evaluation result instead of freezing while it's computed. The same off-to-the-side idea runs the material pipeline — shown in the diagram below.
A delivers each task "at least once" — occasionally the same task arrives twice. To make reprocessing safe, each learning event carries an key, so a repeated delivery doesn't count the same practice twice.
All these moving parts talk to each other over — the standardized way two systems exchange requests and answers.
6What we learned
The AI is the easy part; the learning science is the hard part. Making the model write a sentence or extract words is quick. Deciding when a word should come back, what counts as progress and how to keep practice honest took far more thought than any prompt. The product is the pedagogy, not the AI.
Never let the AI block the basics. We learned to design every AI feature as an optional layer on top of a practice that already works on its own. If the AI is unavailable for any reason, the person keeps learning. Treating AI as an enhancement, not a dependency, made the whole app sturdier.
And a principle we carried from day one: gamification serves the learning, never the other way around. It's tempting to reward every tap to boost numbers, but that teaches people to farm points, not to learn. We respect privacy and the law (LGPD) and keep the rewards tied to real learning behavior.
7What this means for your company
The IdLingo mechanic is simple: take words and their meanings, and make people revisit them on a spaced schedule until they stick. We built it for English, but nothing about the engine is tied to English — or even to a language. Any set of "term and meaning" fits: a new language, the technical concepts of a field, a company's own acronyms and jargon. Here's how that same mechanic travels to other contexts.
Every company has its own vocabulary: internal acronyms, product names, team jargon. Load those terms and their meanings and let spaced repetition bring them back until a new hire stops guessing — the fastest way to make someone feel at home in the company's language.
Point the mechanic at the concepts of a field instead of a language: the terms, patterns and definitions a team works with. It helps beginners learn them for the first time and keeps seniors sharp by bringing concepts back for review before they fade.
The language part isn't limited to English either. The same build-from-what-you-consume plus spaced-repetition approach works for any new language someone wants to learn — the content changes, the mechanic stays the same.
The takeaway: wherever there are terms and meanings worth retaining — a language, a field, a company's own words — making people revisit them on a spaced schedule beats cramming a list once. It works for beginners and seniors alike. That's the piece worth adapting to your context.