How to Make an App Like Memrise

Building a language learning app that competes with Memrise means solving a specific set of engineering problems: spaced repetition, user-generated content, gamification loops, and multi-platform delivery. This post breaks down how those systems actually fit together.

What Makes Memrise's Architecture Different From a Typical EdTech App?

Most EdTech apps are content delivery systems with a quiz layer bolted on. Memrise is different because its core value is the spaced repetition engine, not the content itself. The content is almost incidental. That distinction drives every architectural decision.

Memrise uses a variant of the SM-2 algorithm (originally published by Piotr Wozniak in 1990) to schedule flashcard reviews. The algorithm tracks how well a user recalled an item, then schedules the next review at an interval that maximises long-term retention while minimising review sessions. Getting this right requires storing per-user, per-item recall history. At scale, that's a lot of rows. If you're designing for 10 million users each learning 500 words, you're looking at 5 billion recall events before you've even handled streaks, leaderboards, or course completions.

The other thing Memrise does that most apps don't is user-generated content. Courses created by the community, mems (mnemonic images and phrases), and community translations all need a moderation pipeline and a content storage strategy that doesn't couple content to the core learning engine.

How Does the Spaced Repetition Engine Actually Work at Scale?

The SM-2 algorithm is simple to implement. The scaling problem is the scheduler.

Every time a user completes a session, you need to:

• Update the ease factor for each reviewed item
• Compute the next review timestamp
• Enqueue that item for future delivery

If you're running review sessions for millions of users simultaneously, naively hitting a relational database for each item update will kill you. The standard approach is to write review outcomes to a queue (Kafka or RabbitMQ work well here), process them asynchronously, and write the updated schedule back to a fast-read store like Redis for upcoming session delivery, with PostgreSQL as the durable record.

Choosing Between SM-2 and More Recent Algorithms

SM-2 is predictable and well-understood. FSRS (Free Spaced Repetition Scheduler), which Anki adopted in 2022, uses a machine learning model trained on recall data and consistently outperforms SM-2 in retention benchmarks by around 15–20%. If you're building from scratch today, FSRS is worth the implementation cost. The model weights are publicly available and the algorithm is well-documented.

The trade-off: FSRS requires more data per user before its predictions stabilise. For users in their first week, the difference is negligible. For users with 3+ months of history, it's meaningful.

Data Model for Review History

At minimum, each review event needs: user ID, item ID, timestamp, response quality (0–5 in SM-2), computed next interval, and updated ease factor. Keep this table append-only. Never update historical rows. Derived state (current ease factor, next review date) lives in a separate schedule table that you recompute on write. This keeps your analytics clean and makes debugging scheduling bugs straightforward.

Content Architecture: Courses, Items, and User-Generated Mems

Memrise's content model has three layers: courses, levels, and items (words or phrases). On top of that sits the mem layer, where users attach images and mnemonics to items.

The cleanest way to model this is to keep course structure and item content separate from user-generated overlays. Course and item data lives in PostgreSQL. Mems and community contributions live in a separate service with their own store. This lets you moderate and index community content independently without touching the learning engine.

For media (images, audio clips, video mems), use object storage (S3 or GCS) and serve via a CDN. Memrise uses video clips of native speakers, which are typically 2–5 seconds long and compressed to under 1 MB. At 10,000 concurrent learners watching the same clip, CDN caching is non-negotiable.

What Does the Gamification Layer Actually Require?

Streaks, points, leaderboards, and badges sound simple. They're not, because they interact with each other in ways that create consistency problems.

A streak is a function of the user's local timezone, not UTC. If you store streak data in UTC and your user is in Mumbai, their midnight is 18:30 UTC the previous day. Get this wrong and you'll break streaks for users in UTC+5:30 and beyond, which is a high-traffic demographic for a language app.

Leaderboards are a classic read-heavy, write-heavy problem. Weekly leaderboards that update in real time for millions of users need a Redis sorted set, not a SQL GROUP BY. Write points to Redis on session completion, and periodically checkpoint to PostgreSQL for durability. Accept eventual consistency on leaderboard rankings. Users don't need millisecond-accurate rank updates. They need rank updates within a few seconds of a session completing.

Badges and achievements need a rules engine. Hard-coding badge logic is fine for the first 10 badge types. After that, you need a configurable system where new achievements can be defined without a deployment. A simple event-driven rules engine where session completion events are evaluated against stored achievement criteria is enough. You don't need a complex CEP system for this.

Mobile vs. Web: Where Should You Invest First?

Memrise's core usage is mobile (iOS and Android account for the majority of sessions in most language learning apps). But the web version matters for onboarding and for users who study at a desk.

Flutter is a reasonable choice if you want a single codebase for iOS and Android with near-native performance. React Native is the alternative, with a larger ecosystem but more bridging overhead for complex animations. If your gamification layer involves a lot of custom animations (which Memrise's does), Flutter's Skia/Impeller rendering pipeline gives you more control.

For offline support, which is critical for a learning app, you need local SQLite storage for due items and review outcomes, with a sync layer that handles conflict resolution when the user comes back online. The conflict rule is simple: server wins for schedule state, client wins for review outcomes recorded offline.

Building the Content Recommendation System

Memrise's "Learn with Locals" video selection is recommendation-based. At a basic level, this means matching a user's current vocabulary level to video clips where the vocabulary density (proportion of known to unknown words) sits in the comprehensible input zone (roughly 95–98% known words, per Krashen's Input Hypothesis).

You don't need a neural recommendation system on day one. A vocabulary coverage score computed per video at index time, stored in PostgreSQL, and filtered by the user's known word set is good enough to get into beta. Graduate to a collaborative filtering model once you have 50,000+ users with meaningful session histories.

Conclusion

The core of a Memrise-like app is a scheduling engine, a content model that separates structure from community contribution, and a gamification layer that handles timezone and consistency edge cases correctly. Get those three things right and the rest is execution.

If you're deciding where to start, build the spaced repetition engine first. Everything else depends on it. A working scheduler with static content will tell you more about your product than a polished UI with random review order.

If you'd like to talk through the architecture for a specific language learning product, the team at Sodio has experience building the underlying systems described here.

---

FAQ

How much does it cost to build an app like Memrise? A production-ready MVP with a spaced repetition engine, course creation tools, and iOS/Android apps typically runs between $80,000 and $200,000 depending on team location and feature scope. The range is wide because offline sync, video content, and a recommendation layer each add significant complexity and development time.

How long does it take to build a language learning app? A focused MVP (spaced repetition, static courses, basic gamification) takes 4–6 months with a team of 4–5 engineers. Adding user-generated content, video mems, and a real-time leaderboard pushes that to 9–12 months. Timeline is mostly driven by the content pipeline and moderation tools, not the learning engine itself.

What is the best algorithm for spaced repetition? FSRS (Free Spaced Repetition Scheduler) outperforms SM-2 in controlled studies by 15–20% on retention metrics. SM-2 is simpler to implement and sufficient for an MVP. If you're building for serious language learners who will use the app for months, FSRS is worth implementing from the start.

Do I need a separate backend service for user-generated content? Not at first. A monolith with a well-isolated content module is fine until you're moderating thousands of submissions per day. The trigger to split is usually moderation queue latency affecting the core learning experience, not a specific user count.

Can a language learning app work offline? Yes, and for a learning app it's a near-mandatory feature. The standard approach is to sync due items and course content to local SQLite on the device, record review outcomes locally, and sync back on reconnection. The main engineering challenge is conflict resolution when the same item is reviewed on two devices while offline.

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