How to Make an App Like Lingvist

A practical breakdown of the architecture, ML pipeline, and product decisions behind a spaced-repetition language learning app — from someone who has built systems like it.

What Lingvist Actually Does Under the Hood

Lingvist is not a gamified flashcard app. It uses a spaced-repetition algorithm layered on top of a statistical model of your vocabulary knowledge. Every card presentation updates a probability estimate of whether you know a word. The scheduling engine uses that estimate to decide when to show the card again.

The core loop is:

1. User sees a word in a sentence context
2. User responds (typed or selected)
3. The system updates the word's memory model for that user
4. The scheduler places the next review at the optimal interval

The "optimal interval" is derived from a variant of the SM-2 algorithm, similar to what Anki uses, but Lingvist extends it with a probabilistic model trained on aggregate user data. That distinction matters when you're building — you need to decide upfront whether you're shipping a static SRS scheduler or a data-driven adaptive one. They're meaningfully different in complexity and infrastructure cost.

What Does the Technical Stack Look Like?

Mobile and Web Clients

Lingvist runs on iOS, Android, and web. If you're building a comparable product, the decision between React Native, Flutter, and separate native codebases comes down to how much the learning experience depends on native rendering.

For most edtech apps at early scale, Flutter is a reasonable choice. It gives you a single Dart codebase, consistent UI across platforms, and solid performance for the kind of interactions a vocab app needs: text input, animations, audio playback. If your UX involves heavy camera use or device sensor integration, reconsider. Flutter's plugin ecosystem has gaps there.

React Native is a viable alternative if your team is already deep in JavaScript. The trade-off is that bridging to native modules adds complexity when you need low-latency audio or custom keyboard behaviour, both of which matter in language learning.

Backend Services

The backend needs to handle a few distinct concerns:

• User session and progress state: Which words has this user seen, what are their current memory estimates, when is the next review due?
• Content delivery: The sentence corpus, audio files, translations
• ML inference: Scoring responses and updating memory models in near real-time
• Analytics pipeline: Aggregate learning data that feeds model retraining

A microservices split makes sense here, but only along those seams. Don't over-fragment. The session state service and the ML inference service should be separate because they scale differently and have different latency requirements. The content service and analytics pipeline can be monolithic at first without causing pain.

For the session state, a PostgreSQL database with Redis caching works well. Memory model parameters per user per word are small records, but you'll have millions of them. Index on (user_id, word_id, next_review_at) from day one.

The ML Pipeline

This is where most of the differentiation lives. The memory model is typically a two-parameter exponential decay function: stability (how long memory persists after a successful review) and retrievability (the current probability of recall). The FSRS algorithm, published in 2022, is the current state of the art for open SRS scheduling and outperforms SM-2 on most benchmark datasets. It's worth starting there rather than building SM-2 and iterating.

Training requires historical review data: stimulus, response, response time, and outcome. Cold-start is a real problem. New users have no history, so you initialise their parameters from population priors. As they accumulate reviews, you update toward their personal parameters using Bayesian updating or gradient descent on a per-user basis.

You need a retraining loop. The model that ships on day one will drift as your user base grows. Set up a weekly or fortnightly retraining job using something like Apache Airflow or Prefect, pulling from your analytics store. Keep a holdout set. Track mean absolute error on predicted recall probability against actual outcomes.

How Do You Build the Content Layer?

Vocabulary apps live or die on content quality. Lingvist built its corpus from real-world text sources, then extracted high-frequency words in context. The key insight is that the sentence is as important as the word. A word seen in a natural sentence is encoded more durably than the same word on an isolated flashcard.

Your content pipeline needs:

• A source corpus (news articles, books, subtitles — frequency lists like SUBTLEX are well-studied)
• A frequency ranker to prioritise which words to include
• A sentence extractor that finds natural, unambiguous example sentences
• A difficulty classifier so you're not showing a beginner a sentence with five unknown words
• Audio generation or recording for target-language pronunciation

For audio at scale, TTS has become viable. Google Cloud Text-to-Speech and Amazon Polly both support a wide range of languages with neural voices. The quality gap between TTS and professional recording has narrowed significantly since 2020. For major languages, TTS is acceptable. For rarer languages, you may still need human recording.

How Much Does It Cost to Build?

This is the question most people ask too early. Cost depends heavily on scope.

Component	Minimal build	Full Lingvist-equivalent
Mobile app (Flutter)	8–12 weeks, 2 engineers	20–30 weeks, 3–4 engineers
Backend API + DB	4–6 weeks, 1–2 engineers	10–14 weeks, 2–3 engineers
ML pipeline (FSRS)	3–4 weeks, 1 ML engineer	8–12 weeks, 2 ML engineers
Content pipeline	2–3 weeks	6–8 weeks
Admin/CMS	Optional at MVP	4–6 weeks

A focused MVP, one language pair, FSRS scheduling, no adaptive difficulty, basic content pipeline, can be built in four to five months with a team of four. A full adaptive platform with multiple language pairs, personalised difficulty, and a retraining pipeline is closer to twelve months.

Don't underestimate the content cost. Licensing corpus data or building a clean pipeline to generate it from public sources takes time that doesn't show up in engineering estimates.

Should You Build In-House or Work With a Development Partner?

If your team already has ML engineers who have worked with SRS systems and mobile developers who have shipped production apps, building in-house is viable. The technology is well-understood. The FSRS algorithm is open source. Flutter is mature.

If you don't have that depth, partnering with a team that has shipped similar systems cuts the iteration cycles significantly. The architecture decisions, the cold-start problem, the content pipeline edge cases — these are solved faster by people who have hit the same walls before.

The honest trade-off: an external team builds faster initially but adds coordination overhead. An internal team is slower to start but owns the knowledge completely. If this product is a long-term core asset, plan for the knowledge transfer or build in-house from the start.

Conclusion

Building a Lingvist-equivalent is a well-scoped engineering problem. The algorithms are documented, the tooling is mature, and the architecture decisions are knowable upfront. The complexity sits in three places: the ML pipeline and its retraining loop, the content pipeline and corpus quality, and the cold-start problem for new users.

If you're planning this build, start with FSRS, a single language pair, and a clean content pipeline. Get real user data before you invest in personalisation. The model only improves with signal.

If you'd like a technical scoping session with the Sodio team, reach out directly. We'll tell you what's realistic for your timeline and budget without overselling it.

FAQ

How long does it take to build a spaced-repetition app? A focused MVP with one language pair, FSRS scheduling, and a basic content pipeline takes four to five months with a team of four engineers. A full adaptive platform with multiple languages, personalised difficulty, and a continuous retraining loop is closer to twelve months of development.

What algorithm does Lingvist use for spaced repetition? Lingvist uses a variant of SM-2 extended with a probabilistic memory model trained on aggregate user data. For new builds, FSRS (published 2022) is the better starting point. It's open source and outperforms SM-2 on recall prediction benchmarks.

What's the hardest technical problem in building a vocab learning app? Cold-start. New users have no review history, so the memory model can't personalise yet. You initialise from population priors and update toward personal parameters as reviews accumulate. Getting this right without a poor early experience is the core product-engineering tension.

Can TTS replace human voice recording for language apps? For major languages, yes. Google Cloud Text-to-Speech and Amazon Polly neural voices have improved significantly since 2020. For less-resourced languages, quality is still inconsistent and human recording may be necessary. Test your target language specifically before committing to TTS.

Flutter or React Native for a language learning app? Flutter is the better default for this use case. A single Dart codebase, consistent cross-platform UI, and solid performance for text input, animations, and audio playback. React Native adds complexity when you need low-latency audio or custom keyboard behaviour, both of which are common in language apps.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.