Readable English

Context

Readable English is an evidence-based reading intervention for striving readers — students who’ve fallen behind, learners with dyslexia, and people learning English. Its core idea is a set of 21 glyphs that make English pronunciation predictable. Learners first “break the code” in a space-themed mission, then practise daily with short, scaffolded lessons: decoding, vocabulary, fluency and comprehension.

What makes the practice work is that the app listens. Learners read words and whole passages aloud, and the app follows along — word by word, in real time.

Engineering nuance

1. One on-device speech engine on every platform

Constraint. Feedback has to land while the learner is still on the word. A cloud round-trip adds latency that breaks that loop, classrooms often have poor connectivity, and platform speech APIs behave differently on iOS, Android and the browser.

Decision. Run speech recognition entirely on-device with sherpa-onnx on all three platforms — iOS, Android and Web — using a memory-optimised local model.

Trade-off. Shipping and tuning a model is more work than calling an API, and it has to fit on low-memory school devices. In return: fast recognition, identical behaviour everywhere, it works offline, and student audio never leaves the device.

2. A matching algorithm, not a transcript

Constraint. A speech recogniser guesses what you said. A reading tutor already knows what you should say — and children skip words, repeat themselves, self-correct and mispronounce. A raw transcript is useless for feedback.

Decision. I built a text-matching algorithm that aligns the recogniser’s output against the expected passage and works out, accurately, which words have actually been spoken — so the app can highlight progress as the learner reads and pinpoint exactly where they stumbled.

Trade-off. It’s product logic we own and have to tune, but it turns generic speech recognition into reading assessment.

3. One engine, many games

Constraint. Each skill needs a different kind of practice, but they all depend on the same listen-and-match loop.

Decision. Build the speech + matching engine once and put multiple games on top of it, each targeting one skill:

• Decoding — Falling Words: read the words aloud before they land.
• Vocabulary — Vocab Vault: practise key words in context with real-time voice checks.
• Fluency — Space Race: read a full passage aloud to stay ahead of the spaceship.

Games mix timers, audio, animation and live speech input, so each one is modelled with explicit state (BLoC), with GetX handling app-level wiring.

4. An AI pipeline for levelled content

Constraint. Every game needs a steady supply of passages, word lists and questions — and each one has to be pitched at the learner’s actual reading level. Too hard and a striving reader gives up; too easy and nothing improves. That’s far more levelled content than a team can write by hand.

Decision. An AI pipeline that generates app content targeted to specific Lexile levels and reading grade levels, so every learner practises with material matched to where they are.

Trade-off. Generated content still needs guardrails and review to stay accurate and age-appropriate, but the library can grow at the pace the product needs — at every level.

5. Tune in production, without a release

Firebase Remote Config for tunable behaviour, Analytics to see where learners struggle, and Crashlytics to keep stability high across three platforms — so the team iterates in days, not store-review cycles.

Outcome

• One Flutter codebase and one on-device speech engine across iOS, Android and the Web.
• Word-accurate reading feedback that works with or without a connection.
• A family of practice games for decoding, vocabulary and fluency — fed by AI-generated content levelled by Lexile and reading grade.
• In-app subscriptions integrated end-to-end, supporting a sustainable business model.