How to Build a Language Learning App: The Systems Behind the Streak

Nguyen Manh Thang Chief Executive Officer, AgileTech Vietnam

Published: August 21, 2026
Read time: 13 min

In short

Building a language learning app means building five systems, and the screens are the smallest of them. The learning engine schedules what each user sees next (spaced repetition plus a curriculum graph). The content pipeline produces and maintains thousands of exercises per language, with native audio, which is a production operation rather than a database. The speech layer scores pronunciation and, in 2026, powers AI conversation practice, the feature that now defines competitive parity. The habit layer (streaks, reminders, progression) decides retention, which decides everything economically. And the analytics layer measures actual learning, not just engagement, so the product improves on the right metric. A credible MVP with one language pair, a recall-based exercise loop, native audio and basic spacing lands in the low-to-mid six figures of engineering effort framed as a model; the AI tutor and each additional language multiply content and speech costs, not just translation costs.

Language learning apps look simple from the outside: flashcards with a mascot. The teams that build them discover a different product underneath: a scheduling engine making per-user decisions every few seconds, a content operation producing curriculum at industrial scale, a speech stack scoring audio in real time, and a habit machine tuned as carefully as anything in gaming. The visible lesson screen is the smallest system of the five.

This guide is the builder's map. It covers the learning engine (spaced repetition, curriculum graphs, exercise types that train recall rather than recognition), the content pipeline and its licensing choices, the speech and AI-conversation layer that now defines parity, the habit and monetization mechanics, the architecture that serves all of it offline-first, and an honest cost model with every figure framed as illustrative. It is a companion piece: our comparison of the leading apps covers what each incumbent actually trains, and it doubles as your competitive teardown.

One positioning note before the systems: the market rewards focus. The incumbents own "all languages, all levels, free"; a new entrant wins with a sharper promise, one language pair done deeply, one audience (heritage speakers, exam candidates, medical professionals), or one mechanism (conversation-first, input-first) executed better than a generalist can. Every architecture decision below gets easier once that wedge is chosen.

Key takeaways

The exercise scheduler is the product. What a learner sees next, chosen by a spaced-repetition algorithm woven through a curriculum graph, drives every outcome that matters; the visible screens are a thin shell over that decision.
Content is an operation, not an asset you finish: each language pair needs thousands of exercises, native-speaker audio, and continuous error-report triage. Teams that budget content as a one-time cost run out of curriculum exactly where learners hit the intermediate plateau.
Speech went from differentiator to table stakes: learner-tuned pronunciation scoring and an AI conversation mode are now expected, and the engineering (streaming audio, latency budgets, cost-per-minute control) is its own workstream.
Retention mechanics are load-bearing economics: language apps monetize on subscriptions, subscriptions depend on habits, and the streak, reminder and progression systems deserve the same engineering seriousness as the learning engine.
Measure learning, not just engagement: session counts can rise while learning falls (easy reviews feel good). Instrument recall rates, level progression and skill assessments, or the product will optimize itself into a pleasant, ineffective toy.
Scope the MVP as one language pair, one strong loop: recall-based exercises, native audio, real spacing, offline basics. Add the AI tutor when the loop retains, and add languages only when the content pipeline is an assembly line rather than a heroic effort.

The learning engine: spacing, curriculum, and exercise design

The heart of the product is a scheduler answering one question per user, continuously: what is the most valuable thing to show this learner right now? The canonical machinery is spaced repetition: every item a learner studies (a word, a phrase, a grammar pattern) carries a memory model, and review is scheduled just before predicted forgetting. The classic SM-2 family of algorithms is simple and proven; the modern free-spaced-repetition-scheduler (FSRS) family fits a forgetting curve per user and item from review history and schedules measurably better. Either way, the engine is a small amount of code wrapped in a large amount of data discipline: every exposure, answer and latency logged per item, because the log is what the scheduler learns from.

Pure spacing is not a curriculum, and this is where language apps diverge from flashcard tools. Items depend on each other: past-tense exercises presuppose present-tense verbs, restaurant dialogue presupposes food vocabulary. Real products model the curriculum as a dependency graph (skills unlock skills, items belong to skills) and run the spacing algorithm within the frontier that graph exposes. The scheduler then balances three demands that genuinely compete: reviews that are due (memory maintenance), new material the graph has unlocked (progress), and remediation where error rates show a weak foundation. The blend ratio is a product decision with measurable consequences: too many reviews feels like homework, too much new material silently destroys retention of the old.

Exercise design decides what the app actually trains, and the honest hierarchy is uncomfortable for engagement metrics: recognition exercises (tap the matching tile, multiple choice) are cheap to build, feel pleasant, and train the least; recall exercises (type the translation, say the sentence, fill the gap from memory) are harder, feel worse, and build durable ability. A defensible product mixes them deliberately, recognition to introduce, recall to consolidate, and production (free-form sentence building, speaking) to convert knowledge into use. Grading is its own subsystem: accepting alternative correct answers, tolerating typos without accepting errors, and giving feedback that teaches rather than just judging ("almost: gender of the article" beats a red X) is where language pedagogy becomes code.

Two engine decisions deserve architecture attention early because retrofits are painful. First, the item model must separate content from memory state: a learner's strength on "der Tisch" is a relationship between user and item, not a property of either, and the schema that gets this wrong cannot support content updates cleanly. Second, the scheduler must run offline: learners study on planes and subways, so the client needs enough of the model (due queue, item data, a local scheduling approximation) to run sessions disconnected and reconcile the log later. Conflict rules for that reconciliation, two devices, one user, divergent histories, are tedious exactly once, at design time, and permanently if deferred.

The engine vocabulary this guide uses

Spaced repetition (SRS): Scheduling reviews at expanding intervals timed to just before predicted forgetting. The core memory machinery of every serious language app.
FSRS: The modern open scheduler family: fits a per-user, per-item forgetting curve from review history. Measurably better spacing than the classic SM-2 lineage.
Curriculum graph: The dependency structure between skills and items: what unlocks what. The scheduler works within the frontier this graph exposes.
Recognition vs recall: Choosing the answer among options versus producing it from memory. Recall is harder and builds durable ability; the mix is a core product decision.
Item / memory-state split: Content (the exercise) and a learner's strength on it are separate entities. The schema decision that makes content updates and analytics possible.

An illustrative split of where engineering and production effort goes in a credible language learning app. The visible screens are the smallest system.

The content pipeline: curriculum at industrial scale

Content is where language app budgets go to be humbled. A single language pair at credible depth, beginner through low-intermediate, means thousands of exercise items: sentences with acceptable-answer sets, distractors, grammar notes, hints, and audio for essentially every item. That corpus must be written per language pair, not translated from a master: teaching Spanish to English speakers and English to Vietnamese speakers are different curricula with different contrast points, false friends and error patterns. Teams that machine-translate a master curriculum ship content that native speakers screenshot for sport, and the reputational cost outlives the fix.

The pipeline that works is an editorial production line with software around it. Curriculum designers define the skill graph and item specifications; native-speaking writers produce items in a structured authoring tool (never spreadsheets, which cannot validate answer sets or preview exercises); reviewers check pedagogy and naturalness; and an automated gate lints everything: audio present, answer sets non-contradictory, vocabulary within the level's bounds, no orphaned dependencies. Post-launch, the pipeline's job shifts to maintenance: learner error reports ("my answer should be accepted") arrive by the hundreds, and triaging them is permanent editorial staffing, not a launch-month task. Budget content as an operation with monthly cost, because that is what it is.

Audio deserves its own paragraph because it is half the learning value and a real cost line. Learners need native-speaker audio at natural speed (and ideally a slow variant), consistent voice identity per course, and studio-adjacent quality, background hum and level jumps read as cheapness within seconds. The 2026 decision is synthesis versus recording: neural text-to-speech in major languages is now good enough for item-level audio at a fraction of studio cost, with per-item regeneration when content changes, while dialogue and story content still benefits from human actors, and smaller languages expose TTS quality gaps fast. Most credible pipelines mix both: TTS for the long tail of items, recorded voices for the content that carries the course's personality.

Then there is the build-versus-license question for the curriculum itself. Licensing an established course (publisher content, frequency lists, graded readers) buys speed and pedagogical credibility at the price of per-user royalties and content you cannot freely restructure into your exercise types. Original content costs more up front, fits your engine exactly, and becomes an asset competitors cannot copy. The pragmatic pattern for a new entrant: original core curriculum for the wedge language pair (it must fit the engine), licensed or public-domain material for supplementary input (readers, stories), and aggressive reuse of open frequency data for corpus decisions. Whatever the mix, get content-update mechanics right in the schema from day one: items version, learner memory state survives item edits, and a fixed typo must not reset ten thousand users' review schedules.

Content sourcing options, compared

Strategy	Speed to launch	Cost shape	What you give up
Original curriculum	Slowest: months per language pair	High up-front, then maintenance staffing	Time; nothing structurally
Licensed course content	Fast: weeks to integrate	Royalties per user or per course, forever	Freedom to restructure into your exercise types
TTS-first audio, mixed voices	Fast for item audio	Per-character synthesis, cheap regeneration	Personality in dialogues; quality in small languages

The three sourcing strategies for course content, with the trade each one makes.

An illustrative model of recall probability over time: unreviewed material decays fast, while spaced reviews reset and flatten the curve.

Speech and the AI tutor: the parity feature of 2026

Speech features climbed from novelty to expectation in one product generation, and they arrive in two tiers. Tier one is pronunciation scoring: the learner speaks a prompted sentence, the app grades it and localizes the problem ("the second vowel"). The naive build, run generic speech-to-text and compare strings, fails learners systematically: recognizers trained on fluent speech either autocorrect learner errors (scoring them right) or reject accented-but-correct speech (scoring them wrong). Purpose-built pronunciation-assessment APIs exist (major cloud vendors ship them) and score phoneme-level accuracy against a reference; they are the sensible default, with in-house models a later optimization for the languages where you have data scale.

Tier two is the AI conversation tutor, and in 2026 it defines competitive parity: a spoken, adaptive dialogue partner that role-plays scenarios, corrects on request, and remembers the learner across sessions. The architecture is a pipeline with a latency budget: streaming speech-to-text, a language model turn (system-prompted with the learner's level, target vocabulary, correction policy and scenario), and streaming text-to-speech back, with the whole loop needing to feel conversational, roughly a second to first audio, not a walkie-talkie exchange. Realtime speech-to-speech APIs collapse the pipeline and the latency at a higher per-minute price; the classic pipeline stays cheaper and more controllable. Either way, engineering effort concentrates in the unglamorous edges: barge-in (the learner interrupts the tutor), noisy environments, and graceful degradation when the network stutters.

The pedagogy layer on top of the model is what separates a tutor from a chatbot, and it is prompt-and-state engineering your team owns. Level adaptation: the tutor must constrain its vocabulary and pace to the learner's frontier, which means feeding it the learner model, not just a level label. Correction policy: interrupting every error kills fluency practice, so corrections batch into a post-session recap unless the learner asks live. Scenario design: the high-value sessions rehearse the learner's actual life (the job interview, the in-laws, the clinic), which argues for a scenario library plus free-form mode. And session memory: recurring errors, mastered topics and yesterday's conversation must persist into today's system prompt, because memory is the feature users describe as "it knows me".

Cost control is the difference between a flagship feature and a margin disaster, because AI conversation is metered in expensive minutes while subscriptions are flat. The levers that work: cap included tutor minutes per tier and sell top-ups; route by capability (smaller models handle beginner scripted scenarios; reserve frontier models for free conversation); cache and reuse TTS for repeated tutor lines; and instrument cost per active user weekly, because model pricing and usage mix both move. Teams that ship the tutor without a metering design learn unit economics the expensive way, in their first invoice month.

The conversation loop as an architecture: streaming speech in, a level-aware model turn, streaming audio out, with the learner model feeding both ends.

Habit mechanics and monetization: the retention machine

Language learning has a brutal baseline: the modal outcome of every method, app or classroom, is quitting within weeks, and a subscription business cannot survive the baseline. This is why the habit layer is load-bearing economics rather than gamification garnish. The core mechanics are known: a streak with real emotional weight (plus repair mechanics, freezes and earn-backs, because a streak lost to a flight ends accounts), a daily goal sized small enough to survive bad days, reminders that reference actual state ("your 47-day streak" beats "time to practice!"), and visible progression through the curriculum graph. Each mechanic is an experiment surface, and the incumbents' decade of tuning is why their retention embarrasses newcomers who treat these as checkbox features.

The design tension to manage consciously: engagement mechanics and learning outcomes are correlated but not identical, and they diverge exactly where the product is tempted to cheat. Easy review sessions protect streaks and inflate accuracy; recall and production exercises grow ability and feel like work. Leagues reward minutes, not skill. The honest resolution is instrumentation (the analytics section below) plus a design principle: gamify showing up, never dumb down what happens after the learner arrives. Products that let engagement metrics steer exercise difficulty drift into pleasant ineffectiveness, and their users eventually notice they cannot speak.

Monetization in this category has a well-mapped structure: free tier with ads and limited features (hearts, gated content) driving scale; a subscription removing limits and unlocking the premium features (offline, the AI tutor, personalized review); and increasingly a top tier around the tutor and human-adjacent features. The free tier is not charity, it is the acquisition engine and the habit incubator, and its generosity level is a strategic decision: too stingy and the habit never forms, too generous and conversion starves. Family plans, student pricing and lifetime offers each have known effects on the mix; the figure to watch weekly is trial-to-paid conversion by cohort and the tutor's attach rate, because the tutor is both the strongest conversion driver and the largest cost line.

Two retention systems get underbuilt by first-time teams and pay for themselves fast. Placement and win-back: adults arrive with prior knowledge, and forcing a false beginner through "hello, my name is" churns them in a session, so a placement test that lands people at their frontier is an onboarding feature with retention consequences. And the lapse pipeline: learners who miss days are not lost, they are the largest addressable audience the product has, and a designed return path (streak repair, a shortened re-entry session, a "review what you were forgetting" hook) recovers a meaningful share of them. The incumbents run these as first-class systems; a new entrant that skips them is leaving its own users on the table.

Habit and monetization: what the retention math rewards

Do this

Size the daily minimum for bad daysA goal small enough to survive the worst Tuesday keeps the habit alive; ambition can live in optional extra sessions.
Build streak repair, not just streaksFreezes, earn-backs and grace windows exist because life exists. A streak that ends permanently ends the account with it.
Gamify arrival, protect difficultyPoints and leagues for showing up; recall and production exercises untouched by engagement tuning. The split keeps the product honest.
Design the lapse return pathA shortened re-entry session plus a memory-state hook ("rescue 12 words you are forgetting") converts guilt into a session instead of an uninstall.

Not this

Letting metrics soften the exercisesRecognition-heavy sessions raise accuracy and retention charts while learning quietly dies. The divergence is measurable if you measure it.
Notifications without stateGeneric "time to practice!" pings train the swipe-away reflex. Reference the streak, the goal, the words at risk, or send nothing.
Starting every adult at zeroFalse beginners are a huge cohort and they churn instantly when patronized. Placement is onboarding, and onboarding is retention.
Unmetered premium AI featuresThe tutor drives conversion and consumes margin. Included-minutes design belongs in the pricing page, not in a post-launch patch.

An illustrative model of user drop-off by lifecycle moment. The mechanics in this section each target one of these cliffs.

Architecture: offline-first clients, an event-logged backend

The client architecture decision that shapes everything else: sessions must work offline, fully, not gracefully degrade. Learners study in transit, and a lesson that stalls on connectivity churns precisely the habit the product depends on. That means the client carries a local database (course content for downloaded units, the learner's memory state, the due queue), runs the scheduler locally, plays audio from an offline cache, and appends every learning event to a local log that syncs when the network returns. Cross-platform frameworks serve this category well, the UI is content-heavy rather than platform-exotic, with the caveat that audio recording, playback latency and background audio need native-quality attention on both platforms.

The sync model is the backend's defining problem, and language apps have a forgiving shape for it: learning events are append-only facts ("user answered item X correctly at time T"), and memory state is a deterministic fold over those events. Sync therefore ships the event log up, merges by timestamp, and recomputes state, with last-write-wins acceptable for preferences and a deterministic merge for review history. Two devices studying offline simultaneously is the edge case to design explicitly; the resolution (union the events, recompute, tolerate a slightly conservative schedule) is simple if chosen up front and miserable if improvised after support tickets arrive.

Server-side, the shape is unexotic and the interesting parts are data flows: an API serving content bundles (versioned, CDN-cached, per-unit downloads sized for mobile networks), an event ingestion path that scales with sessions (every answer is an event; volume is high and bursty around evening reminder sends), the scheduler's server twin for cross-device consistency, and the speech pipeline as its own service boundary, because its latency and cost profile differ from everything else. The content system deserves first-class treatment: editorial tooling, versioned publishing with staged rollout, and the item-versioning discipline from the content section, because "we fixed a typo and broke review schedules" is this category's signature self-inflicted outage.

The analytics layer is what makes the whole machine improvable, and it must be designed around learning, not just engagement. The event log already captures the raw material; the discipline is defining the metrics that matter (per-item recall rates, time-to-mastery per skill, level progression velocity, retention by cohort and by exercise-mix) and wiring experiments to them. A/B infrastructure in this category tests pedagogy, does a higher recall ratio in early lessons improve week-four retention?, which is a slower, more careful experimentation loop than button-color testing, with real ethical texture: learners are trusting the product with their goals. Teams that instrument learning honestly build compounding advantage; teams that instrument only engagement optimize a slot machine.

The reference architecture, component by component

Client (iOS and Android)

Local store: Course content per downloaded unit, memory state, due queue, audio cache
Local scheduler: Runs sessions fully offline; server twin reconciles cross-device
Event log: Append-only learning events, synced opportunistically, merged deterministically
Audio: Offline playback cache; recording path with native-quality latency handling

Backend services

Content API: Versioned bundles, CDN-cached, staged publishing, item versioning
Event ingestion: High-volume, bursty; feeds state recompute and analytics
Speech service: Pronunciation assessment plus the tutor pipeline; own scaling and cost boundary
Learner model: Memory state, level, error patterns; feeds scheduler and tutor prompts

Operations

Editorial tooling: Structured authoring, linting gates, error-report triage queue
Experimentation: Pedagogy-aware A/B infrastructure keyed to learning metrics
Cost telemetry: Tutor minutes, TTS characters, speech API calls per active user, weekly

Cost, team and timeline: an honest model

Every figure in this section is framed as an illustrative model, not a quote; the point is the shape and the ratios, which survive contact with reality better than any absolute number. A credible MVP, one language pair, the recall-based exercise loop with real spacing, native audio, offline sessions, streaks and a free-plus-subscription skeleton, is roughly a five-to-seven person team for five to seven months: two mobile engineers, one or two backend engineers, a designer who owns learning UX (a real specialty), a curriculum lead with native-speaker writers on contract, and a product owner who has personally studied a language with the competitors. That lands the engineering in the low-to-mid six figures, with content production for the first pair adding a meaningful five-figure line on top.

The cost curve after MVP has two multiplicative axes that first-time founders consistently underprice. Each new language pair replays most of the content cost (curriculum, writing, audio, review) and adds speech-quality variance, TTS and pronunciation assessment that are excellent in Spanish may be mediocre in Vietnamese, so language expansion is a content-operations decision, not a localization checkbox. And the AI tutor adds three permanent lines at once: engineering (the pipeline and its edges), model costs that scale with usage rather than revenue, and scenario-plus-prompt content per language. The sequencing that manages both: prove the core loop retains in one pair, add the tutor and prove its attach-and-margin math, and only then expand languages with an assembly-line pipeline.

Where the spend actually goes surprises teams who budgeted from the screens: in the model above, roughly a quarter of total effort is the visible app, and the rest splits across the engine and sync, the speech layer, the content pipeline and tooling, and the habit-analytics-experiment machinery. This ratio is the practical argument for scoping ruthlessly: every feature that is neither the loop, the habit, nor the tutor (forums, dictionaries, chatbots for support, social feeds) is deferrable, and most of the graveyard's language apps died with beautiful peripheral features around an engine that did not retain.

The go-to-market plan belongs in the build plan because this category's economics start hostile: user acquisition against incumbents with free products and decade-old brand habits is expensive, which is why the wedge from the introduction matters operationally, not just rhetorically. A focused audience (one language pair, one profession, one exam, one region) concentrates word of mouth, makes creator partnerships affordable, and gives app-store search a niche to rank you in. The comparison-shopping behavior of this market also works for a focused entrant: learners actively try multiple apps, and the mechanism-by-mechanism teardown of the incumbents is exactly the map of the gaps a wedge product can own. Broader patterns for the category, engagement architecture, completion mechanics, sit in the education app guide.

The model's headline ratios

5 to 7 months MVP timeline, one language pair, framed as a model A five-to-seven person team shipping the recall loop, spacing, audio, offline and the habit skeleton. The tutor comes after retention is proven.

~25% Share of build effort in the visible screens The rest lives in the engine, sync, speech, content tooling and analytics, the systems this guide exists to make visible.

2 axes What multiplies cost after MVP Each language pair replays content production; the AI tutor adds engineering, per-minute model costs and scenario content. Sequence them deliberately.

The build plan: from wedge to shipping loop

Phase zero is the wedge decision, made with users rather than in a document: pick the language pair and audience, interview twenty target learners about what they tried and abandoned, and study the incumbents as a practitioner (actually run the streaks for a month). The output is a one-page thesis: who, learning what, failed by the current options in what specific way, and which mechanism (conversation-first, exam-focused, input-heavy, profession-specific) your product will execute better. Every later dispute about features gets settled against this page.

Phase one builds the loop before the app around it: the item schema with the content-versus-memory-state split, the scheduler (an existing FSRS implementation beats a homegrown algorithm), a structured authoring tool however minimal, and a few hundred items of real curriculum for one unit, with audio. Ship it to a closed cohort as an ugly build and measure the only thing that matters at this stage: do recall rates climb and do people return for day seven? Pedagogy bugs found here cost a rewrite of fifty items; found post-launch they cost a course.

Phase two wraps the proven loop in the retention machine and the business: onboarding with placement, streaks with repair mechanics, reminders keyed to state, the free-tier boundary and subscription, offline downloads, and the analytics dashboards that separate learning from engagement. This is also when content production must become an assembly line, the full first course built out by the editorial pipeline while engineering hardens sync and scale. Launch at the end of phase two is a real product: one pair, one strong loop, honest habit mechanics, measurable learning.

Phase three adds the tutor and expands: the speech pipeline with pronunciation scoring, then the conversation tutor with metered minutes and the pedagogy layer (level adaptation, correction policy, scenario library, session memory), each instrumented for attach rate and cost per user. Language expansion follows only when the pipeline produces a course without heroics and the unit economics of the first pair are proven. The discipline that carries the whole plan: at every phase, the exit test is a learning-and-retention number, not a feature list, because in this category shipped features are cheap and retained learners are the entire game.

The build, phased with exit tests

Wedge and researchWeeks 1 to 4

Language pair, audience, incumbent teardown, twenty learner interviews, the one-page thesis

Done when A wedge statement the whole team can recite
Loop proofMonths 2 to 4

Item schema, FSRS scheduler, minimal authoring tool, one real unit with audio, closed cohort

Done when Climbing recall rates and day-seven returns in the cohort
Product and launchMonths 4 to 7

Placement, streak system, reminders, subscription boundary, offline, analytics; content assembly line runs

Done when Launch with learning metrics moving and trial-to-paid measured
Tutor and expansionMonths 7 onward

Pronunciation scoring, AI conversation with metered minutes, scenario library; new pairs via the pipeline

Done when Tutor attach rate with solvent unit economics; second pair without heroics

Engineering, content and product each carry a distinct workstream through the plan, and the exit tests keep them honest.

Frequently asked questions

How much does it cost to build a language learning app?

Framed as an illustrative model rather than a quote: a credible MVP, one language pair, a recall-based exercise loop with real spaced repetition, native audio, offline sessions and subscription mechanics, runs a five-to-seven person team for five to seven months, landing engineering in the low-to-mid six figures with content production adding a meaningful five-figure line. Costs then multiply along two axes: each new language pair replays most content production, and the AI conversation tutor adds engineering, per-minute model costs and scenario content.

How long does it take to build a language learning app?

A disciplined plan runs in phases: about a month of wedge research and incumbent teardown, two to three months proving the learning loop with a real unit of content on a closed cohort, then two to three more wrapping it in placement, habit mechanics, subscriptions, offline and analytics for launch, roughly five to seven months to a real product in one language pair. The AI tutor and additional languages follow after retention and unit economics are proven, typically from month seven onward.

What features does a language learning app need?

The load-bearing set: a spaced-repetition scheduler woven through a curriculum graph, exercise types that include real recall and production (not just tile-tapping), native-speaker audio on essentially every item, fully offline sessions, a placement test for adults with prior knowledge, streaks with repair mechanics and stateful reminders, and learning analytics that measure recall and progression rather than just engagement. In 2026, pronunciation scoring and an AI conversation tutor with metered minutes define competitive parity. Forums, dictionaries and social feeds are deferrable.

How do apps like Duolingo actually work under the hood?

Three systems do the real work. A scheduler decides what each learner sees next, blending spaced-repetition reviews (timed to just before forgetting) with new material unlocked by a curriculum dependency graph. A content pipeline produces and maintains thousands of exercises per language pair with audio, versioned so fixes do not reset learners' progress. And a habit layer, streaks, repair mechanics, goal sizing, stateful notifications, runs the retention economics. The visible lesson screen is a thin shell over the scheduler's decisions, which is why copying the screens copies the least valuable part.

Should a new language app build its own AI conversation tutor?

Yes for the feature, no for the models. The tutor is now a parity expectation and the strongest subscription conversion driver in the category, but the sensible build assembles it from vendor components: streaming speech-to-text, a language model prompted with the learner's level and correction policy, and streaming text-to-speech, or a realtime speech-to-speech API where latency justifies the price. The proprietary value lives in the pedagogy layer you own: the learner model feeding the prompts, correction and recap design, the scenario library, and session memory. Metered minutes and model routing keep the unit economics solvent.

What is the hardest part of building a language learning app?

Content operations, by a wide margin, followed by retention. Each language pair needs thousands of pedagogically-sound exercises with native audio, written per pair rather than translated from a master, then maintained forever against learner error reports, an editorial production line most software teams have never run. Retention is the second wall: the category's baseline outcome is quitting within weeks, so placement, streak mechanics, lapse recovery and honest learning measurement are load-bearing systems, not polish. The algorithms, by contrast, are largely solved: proven open spaced-repetition schedulers exist to build on.

A language learning app is five systems wearing one screen: the scheduler, the content pipeline, the speech stack, the habit machine and the analytics that keep them honest. We mapped the whole build, and AgileTech engineers education products from spaced-repetition engines to AI tutors with solvent unit economics.