Memstory

One of the strangest things in software projects is that success can start looking exactly like procrastination.

Over the last weeks I’ve spent a lot of time building Memstory. Stories. Word lookup. Memory drills. Grammar drills. Production exercises. Import pipelines. APIs. Admin tools. Content systems. The project slowly transformed from “a language learning experiment” into something that actually resembles a platform.

And then we hit a familiar trap.

The browser version kept getting better.

And because it kept getting better, it became tempting to keep improving it.

Add another cache layer. Refactor another file. Split another component. Clean up another hook. Optimize another loading flow.

None of those things are bad. Most of them are good engineering. The problem is that eventually you wake up and realize you’re polishing the scaffolding instead of building the house.

Memstory was never supposed to be a web application.

The browser version exists for three reasons:

• testing
• content creation
• demos

That’s it.

This week we added a lightweight cache layer for stories and drills. Refreshes are faster. Development is smoother. The application feels more responsive. Most importantly, we achieved that without introducing another architectural rabbit hole.

And then came the more important realization.

The biggest unanswered question in the project is no longer technical.

It’s experiential.

I already know that the lookup works.

I already know that the API works.

I already know that the content pipeline works.

What I don’t know is whether reading a story, tapping a word, checking a translation and continuing the text feels good on an actual phone.

That question cannot be answered by another React refactor.

It can only be answered on a device.

So the next chapter is obvious.

The browser version is no longer the destination.

It’s becoming a launchpad.

The path forward is mobile-first. React Native. Expo. SQLite. Real reading sessions. Real interaction patterns. Real constraints. Real users.

In many ways this is the most exciting phase of the project so far.

For the first time, we’re no longer building systems.

We’re starting to build a product.

One thing became increasingly obvious while building Memstory.

This isn’t one application.

Or at least it shouldn’t be.

It’s the beginning of a series of applications built around the same idea.

Helping people learn languages that are often ignored, underserved or unnecessarily difficult to access.

The first version focuses on Russian.

Not because Russian is the most useful language in the world. Not because it is easy. Quite the opposite.

Russian is difficult enough to force me to think carefully about memory, repetition, contextual recall and how people actually learn.

Building for a difficult language forces better design decisions.

What comes after Russian is becoming increasingly clear.

Farsi.

Then Arabic.

Then Turkish.

After that perhaps Urdu, Hindi or Japanese.

Not because I want to build a giant language platform that covers everything.

The opposite.

The goal is depth.

Not breadth.

I am far more interested in helping someone genuinely learn Farsi than offering twenty languages and doing all of them poorly.

There is also a broader idea behind the language choices.

The future will not be shaped exclusively in English.

It will be shaped in Tehran.

In Istanbul.

In Delhi.

In Karachi.

In Cairo.

In places that many Western technology companies still treat as secondary markets despite their growing importance.

Learning these languages is not only about language.

It is about gaining access to ideas, people, cultures and perspectives that exist outside our own bubbles.

I am also increasingly convinced that difficult languages are often the most rewarding.

Not because they are difficult.

But because they force curiosity.

Nobody accidentally learns Persian poetry.

Nobody casually studies Arabic grammar.

Nobody spends years learning Japanese because it was the easiest option available.

These languages attract people who genuinely want to understand something beyond themselves.

I like building for those people.

Because I am one of them.

For now the focus remains the same.

Finish Russian.

Build Farsi.

Learn what breaks.

Improve the system.

Then move on to the next language.

One conversation, one story and one remembered word at a time.

The project expanded beyond reading into active recall training.

A new drill architecture was introduced that allows multiple learning modes to share the same frontend and backend infrastructure.

Implemented

Built:

• drill categories
• drill decks
• drill cards
• drill APIs
• alphabet drill prototype
• memory drill navigation
• multilingual drill metadata
• language-aware UI framework

Major architectural decision

The system was redesigned around a future where every learning mode can support multiple language pairs.

Instead of hardcoding Finnish translations throughout the application, a persistent study language layer was introduced.

Current support:

• Russian → Finnish
• Russian → English

Planned:

• German
• Swedish
• Spanish
• French
• Persian

Current state

Memstory is no longer merely a story reader.

It is evolving into a language-learning platform built around three connected systems:

1. Reading
   • stories
   • word lookup
   • contextual exposure
2. Memory
   • alphabet drills
   • vocabulary drills
   • phrase drills
   • grammar drills
3. Content operations
   • imports
   • vocabulary management
   • editorial workflows
   • future AI-assisted content generation

The next phase focuses on drill completion, multilingual support and scaling content production.

The vocabulary system evolved from a simple word list into a full relational language database.

Several months worth of future requirements were anticipated and modeled before implementation.

Implemented

Built:

• word → word form architecture
• form-level translations
• grammar labels
• morphology-aware imports
• story occurrence mapping
• unknown-word detection
• lookup normalization
• import batch management

Content production

Created:

• large Russian A1 story corpus
• extensive grammar datasets
• inflected vocabulary datasets
• multi-form translation support

A major design principle emerged:

Everything should be importable.

Manual content creation is now considered an exception rather than the default workflow.

The first development phase focused on validating the core learning architecture rather than building a polished application.

The guiding principle was:

ugly but structurally correct

The goal was to answer a single question:

Can language learning content be modeled as reusable relational data instead of static lessons?

Rather than investing time in visual design, the focus was placed on building the systems that would eventually power stories, vocabulary lookup, memory drills and future language pairs.

Core architecture implemented

Built:

• story model architecture
• relational vocabulary database
• word and word form separation
• translation models
• story-word occurrence mapping
• reusable content structures
• import workflows
• vocabulary lookup pipeline
• offline-first foundation

Frontend prototype

Built:

• story reader
• clickable vocabulary lookup
• memory drill prototype
• story navigation
• reveal interaction flow
• React frontend foundation

Backend platform

Built:

• Django backend
• Django REST API
• Django Admin CMS
• SQLite development database
• vocabulary management workflows
• content import tooling

Infrastructure

Configured:

• Git workflow
• SSH authentication
• dedicated Codeberg identity
• repository management
• local development environment

Major architectural decisions

Several common language-learning approaches were intentionally rejected:

• heavy gamification
• streak mechanics
• mandatory online sync
• token-intensive AI workflows
• opaque NLP pipelines
• complex spaced-repetition systems as a starting point

The project instead embraced:

• editorial control
• relational content models
• exact vocabulary mapping
• lightweight automation
• reusable learning structures
• rapid iteration

The result was the first complete vertical slice capable of reading stories, identifying vocabulary and exposing learning content through a shared backend.