How to Make an App Like Duolingo

Building a language-learning app that people actually open every day is one of the harder product engineering problems you can take on. Duolingo has 74.1 million monthly active users as of 2024. That number is not accidental — it is the result of specific architectural decisions, a well-instrumented engagement loop, and years of A/B testing at scale. This post walks through the technical choices you would need to make if you were building something comparable from scratch.

What Does Duolingo's Architecture Actually Look Like?

Duolingo runs a service-oriented backend. The core services handle user profiles, lesson content, streak tracking, notifications, and the spaced repetition engine. These are not tightly coupled. Each one can be deployed and scaled independently, which matters when a viral moment sends 10x normal traffic.

The content layer is separate from the delivery layer. Lesson content is authored in a CMS (Duolingo built a proprietary one called BIFF), serialised to JSON, and cached aggressively at the edge. This means a content update does not require a backend deploy.

The mobile apps (iOS and Android) are native, not cross-platform. Duolingo made this choice early and has stuck with it. The animation fidelity and gesture responsiveness you see in the app are harder to achieve at the same quality in React Native or Flutter, though both have improved significantly. If you are building an MVP, Flutter is a reasonable starting point. If you are building for the long term and animations are core to your engagement model, plan for native.

The Spaced Repetition Engine

The core of any language app is the algorithm that decides what to show the learner next. Duolingo uses a variant of the Half-Life Regression (HLR) model, which they published in 2016. It predicts the probability that a user will recall a word at a given time, then schedules review sessions to catch items just before they drop below a threshold (typically 50% recall probability).

Implementing HLR yourself requires storing per-user, per-item interaction history. At scale, that is a large dataset. Duolingo reported in their research paper that they trained HLR on 13 million Duolingo student learning traces. You will not have that on day one. Start with a simpler SM-2 implementation (used in Anki), collect data, and migrate to a learned model once you have enough signal.

How Do You Build the Streak and Notification System?

The streak is Duolingo's most powerful retention mechanism. In 2023, Duolingo reported that streak freezes alone are used by millions of users daily. The engineering behind it is not complicated, but it has to be reliable.

A streak is a count of consecutive days with at least one completed lesson. The tricky parts are timezone handling and the definition of "day." Duolingo anchors the streak to the user's local timezone, not UTC. If you store timestamps in UTC and convert at query time, you will get this wrong for users who change timezones or travel. Store the user's timezone explicitly. Evaluate streaks using the user's local calendar day.

Push notifications are the enforcement mechanism. Duolingo sends a reminder if the user has not completed a lesson by a configurable time (default is around 8 PM local time). The notification pipeline needs to:

• Evaluate all users who have not completed a lesson today
• Batch the sends by timezone offset
• Use APNs for iOS and FCM for Android
• Handle delivery receipts and retry failed sends

At scale, that evaluation job runs across millions of users. Duolingo uses a scheduled job that partitions users by timezone bucket and processes each bucket ahead of the local deadline. Use a message queue (Kafka or SQS) to decouple the evaluation from the send. Do not run this as a monolithic cron job — you will hit timeout and memory limits faster than you expect.

What Tech Stack Should You Actually Use?

There is no single right answer, but here is a realistic starting point for a team of 4 to 8 engineers building a Duolingo-style app.

Layer	Recommended Choice	Why
Mobile (MVP)	Flutter 3.x	Single codebase, strong animation support
Mobile (scale)	Native Swift / Kotlin	Full platform API access, better performance headroom
Backend API	Node.js (Fastify) or Go	Low latency, good concurrency primitives
Database	PostgreSQL + Redis	Relational for user/progress data, Redis for streak state and session caching
ML / SRS	Python (scikit-learn, PyTorch)	Standard tooling for HLR or custom models
Notifications	Firebase Cloud Messaging + APNs	Managed delivery, good SDKs
Content CMS	Contentful or custom	Depends on how complex your content graph is
Infrastructure	AWS or GCP	Both have managed services that cover everything you need

Duolingo's own stack includes Python, Scala, and Go on the backend. They use Google Cloud. The specific language matters less than keeping services decoupled and keeping the data model clean.

Monetisation and Subscription Architecture

Duolingo generated $531 million in revenue in 2023, with the majority coming from Duolingo Plus (now called Duolingo Super) subscriptions. In-app purchases accounted for most of this on mobile.

Subscription billing on mobile goes through Apple App Store and Google Play. You do not touch payment card data directly. Both platforms take a 30% cut for the first year, dropping to 15% for subscribers who have been active for more than 12 months (under their respective small business and long-term subscription programmes). Plan your unit economics around this from the start.

Server-side receipt validation is not optional. Both Apple and Google provide receipt validation APIs. Validate on your backend, not just on the client. Store the validated subscription state in your own database and treat the platform webhooks as the source of truth for cancellations and renewals.

If you plan to offer a web subscription to avoid the platform cut, be aware of Apple's guidelines. Directing iOS users to a web payment flow from within the app violates App Store rules and has resulted in app rejections.

What Makes Engagement Actually Work at Scale?

The streak is a loss-aversion mechanism. Users are motivated to continue partly because they do not want to lose what they have already built. The research backing this comes from behavioural economics (Kahneman and Tversky's prospect theory), not from gamification theory.

Leaderboards introduce social competition. Duolingo's weekly leaderboard groups users into leagues of 30. Users compete within their league and the top performers are promoted. The engineering here is a windowed ranking problem. Redis sorted sets handle this efficiently at the cost of some precision.

XP (experience points) need to be awarded for the right behaviours. If you award XP for anything that touches the app, users will game it. Duolingo has iterated on this repeatedly. Award XP for completed lessons, streaks, and correct answers, not for opening the app.

A/B testing infrastructure underpins all of this. Duolingo runs hundreds of experiments simultaneously. You need a feature flag system and an experiment assignment service before you can make data-driven decisions. Start with something like LaunchDarkly or GrowthBook rather than building your own.

Conclusion

Building a Duolingo-scale app is achievable, but the complexity is in the details: timezone-aware streak logic, a properly implemented spaced repetition model, reliable notification pipelines, and a monetisation layer that survives platform policy changes. The architecture itself is not exotic. What makes the difference is getting the data model right from the start, keeping services loosely coupled, and instrumenting everything so you can actually run experiments.

If you are at the stage of deciding what to build and how to structure your team, the most useful next step is to write out your data model for user progress and lesson scheduling. That single document will surface most of the hard decisions early.

---

FAQ

How long does it take to build an app like Duolingo? An MVP with core lesson flow, user accounts, streak tracking, and push notifications typically takes 4 to 6 months for a team of 4 to 6 engineers. A production-grade app with spaced repetition, leaderboards, subscription billing, and A/B testing infrastructure is closer to 12 to 18 months of focused development.

How much does it cost to build a language learning app? Costs vary significantly by geography and team structure. At typical mid-market agency or startup rates, an MVP in the £150,000 to £350,000 range is realistic. A full-featured app with ML components, native mobile builds, and a content management system is more likely to fall in the £600,000 to £1.2 million range over 18 months.

Should I use Flutter or go native for a language app? Flutter is a solid choice for an MVP and for most production apps. If your core product differentiator is animation quality and haptic feedback, native is worth the added cost. Most language apps do not need to go native until they have a proven retention model and are optimising at the margins.

What database should store learning progress data? PostgreSQL works well for user progress, lesson history, and subscription state. Use Redis for session state and streak caching where read latency matters. If you implement a learned spaced repetition model, you will eventually want a columnar store like BigQuery or Redshift for the training data, but that is a later-stage concern.

Do I need to build my own spaced repetition algorithm? Not immediately. SM-2 is open, well-documented, and effective. Implement it first. Once you have enough interaction data (roughly 500,000 to 1 million learning traces), you have a basis for training a more accurate predictive model. Starting with a custom ML model before you have data is premature and expensive.

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