Aphasia Toolkit
IN DEVELOPMENTSpeech Recovery · Cognitive Exercises · LLM-Powered Practice
An adaptive speech and cognition practice application, built for my father after a stroke. It generates exercise content with an LLM and adjusts difficulty to measured performance.
The Problem
Aphasia recovery depends on daily practice between therapy sessions, and the available consumer tools are static: fixed word lists, fixed difficulty, clinical interfaces designed around the therapist rather than the patient. Repetition without variety goes stale fast, and stale practice stops happening.
A stroke survivor practicing at a kitchen table needs the opposite — content that changes every session, difficulty that tracks ability day to day, and an interface that requires no one's help to operate.
Constraints That Shaped the Design
One User, Known Limits
Motor and visual challenges are design inputs, not edge cases: large touch targets, high contrast, one action per screen, voice as the primary input.
Zero-Instruction Operation
Every session must be startable and completable without a manual or a family member in the room. If a screen needs explaining, it's wrong.
Imprecise Speech In
Aphasia-related speech patterns break exact-match recognition, so spoken answers are scored on intent by an LLM instead of transcription equality.
Failure Has a Cost
A wrong difficulty setting isn't churn — it's discouragement. The adaptive logic moves in small steps and errs toward confidence-building.
Technical Approach
Next.js and TypeScript, with the Web Speech API handling voice input and output. Exercise content is generated per session: a photo is analyzed, an LLM produces questions grounded in what's actually visible, and spoken answers are evaluated with tolerance for phonemic errors. No two sessions repeat.
Session results feed a simple performance model that steps difficulty up or down — the LLM supplies variety, but the application owns pacing, difficulty, and scoring deterministically. Progress is logged per session so family and therapists see trend lines instead of anecdotes.
What I Learned
Building for one user with hard constraints is a sharper design exercise than building for a hypothetical market — every feature gets tested against a real person's Tuesday, and anything that doesn't survive contact gets cut. The accessibility work made the application better for everyone who touched it, not just its primary user.
The other lesson: LLM features earn their place only inside deterministic guardrails. Generation is where the model helps; difficulty, pacing, and scoring stay in application code, where behavior is predictable and testable.