A non-engineer built a talking word game so a 94-year-old Nana can play again

Word Coffee Break is a voice-first iOS word game app I'm building for my 94-year-old grandmother, Nana — and for anyone like her. She has macular degeneration and can no longer see well enough to play Scrabble, do crosswords, play Wordle, or read. But the problem isn't unique to her. Millions of people with vision challenges are locked out of word games because those games assume you can see a screen. This app doesn't. It talks, it listens, it plays. No screen-play required. The app features five planned daily games — Word Guess (an audio Wordle), Word Ladder, Anagram Rearrange, Rhyme Match, and How Many Words — all driven entirely by voice. Nana is the primary target user; my 77-year-old mum is testing in parallel. I am not a software engineer. I'm a person who had an idea, cared enough to chase it, and used AI collaboration to turn that idea into something real. This project is mid-build, and I'm being honest about that because the journey matters more than a polished screenshot. The deeper thing I accidentally built is a voice interaction architecture — a deterministic state machine that handles interruptions, silence, cancellation, and iOS lifecycle chaos without falling apart. I didn't set out to build that. I set out to make Nana smile. The architecture emerged when I kept asking "but what happens when she taps the screen mid-sentence?" and "what if she puts the phone down and comes back?" Achievements Voice interaction foundation (working): - Complete voice loop validated on a real iPhone: idle → speaking → listening → processing → idle - Deterministic state machine (TurnManager) coordinating speech synthesis, voice recognition, and game logic without race conditions - Barge-in support — the player can interrupt mid-sentence and the app handles it gracefully - Silence-based timeout detection (3-second window) - Ghost callback elimination — cancelled sessions don't produce phantom responses - Centralized AppServices container preventing SwiftUI lifecycle bugs - Main-thread safety enforced with runtime assertions - Echo Test game providing audio confirmation of voice input — for someone who can't see the screen, hearing their input read back is not a bonus, it's essential accessibility First game — Word Guess (working): - Fully playable audio Wordle with 6 guesses and letter-by-letter spoken feedback (green, yellow, gray) - Rich voice command system: thinking/pause mode, individual guess recall, full recap, hints, give up, repeat - IPA pronunciation fixes so the speech engine says short words correctly - Offline-first — all game logic and word lists are local, no network required Word list and speech recognition discovery: - Started with a curated 250-word list across four difficulty tiers - Testing revealed that Apple's speech recognition has its own vocabulary constraints — many of our words simply weren't in the recognizer's dictionary. This wasn't an AI failure; it was a platform limitation. We had to massively expand the word list to work within those constraints. What's still in progress: - Four remaining games (Word Ladder, Anagram Rearrange, Rhyme Match, How Many Words) - Firebase and Anthropic API integration for automated puzzle generation - TestFlight deployment for family testing Tools AI collaborators: - TARDIS (ChatGPT) — Architectural thinking partner. State machine design, lifecycle safety, threading validation, edge-case detection. Three iterations of deep review. - Smudge (Claude on claude.ai) — Building partner. Swift implementation, debugging, word list curation, context-handoff documentation between AI systems. - CeeCee (Claude Code in VS Code) — Hands-on codebase work. Direct repo access, multi-file editing, and where the real build velocity happened. CeeCee is where Word Guess went from architecture to working game — and where the speech recognition vocabulary problem surfaced during real testing. Development stack: - Xcode + SwiftUI, VS Code + Claude Code - Apple Speech Recognition, AVFoundation (implemented directly, no wrapper libraries) - GitHub for version control and code sharing - Real iPhone hardware for testing (simulator audio is unreliable for voice apps) Methodology My process was less "agile sprint" and more "build, break, learn, repeat — and know when to sleep." Build → Review → Harden → Validate → Reflect - Build a feature with one AI partner - Have a different AI partner review for edge cases - Harden based on what they found - Test on real hardware - Reflect on what I actually understood vs. what I just copied Principles I learned to follow: - Explicit state over implicit behavior. If the app can be in a state, that state should have a name. - Cancellation is a first-class citizen. Half the bugs in voice apps come from not cleaning up when you stop something mid-stream. - Different AI models for different jobs. TARDIS caught architectural risks. Smudge caught implementation bugs. CeeCee built at speed. The combination was stronger than any one alone. - Stop when you're tired. My best code came from focused 2-3 hour sessions. My worst debugging happened past cognitive fatigue. - Test with the simplest possible thing first. The Echo Test exists because I needed to prove the voice loop worked before building five games on a broken foundation. Learnings About AI collaboration: - AI is not a replacement for thinking. It's a replacement for thinking alone. The best outcomes came when I directed the reasoning — "check this for edge cases" rather than "write me an app." - Model selection is an engineering decision. I started with Claude Sonnet and discovered firsthand it wasn't cutting it for deep debugging — so I moved up to Opus. Nobody told me to; I felt the difference and made the call, and then, realizing I was in the wrong tool, handed it off to VS Code using CeeCee. - Cross-review between different AI systems catches things neither catches alone. TARDIS found a threading assumption Smudge had made. Smudge found an API pattern TARDIS suggested incorrectly. - Context handoff is a real skill. Writing a good briefing so a new AI session can pick up where the last left off — that's engineering communication I didn't expect to learn. About building software: - Accessibility-first design produces better architecture. When you can't rely on visual UI as a crutch, you think harder about state, flow, and feedback. - Platform constraints will surprise you. Our careful word difficulty progression hit Apple's speech recognition vocabulary limitations. Not an AI failure — a platform constraint. The plan met reality, and reality won. - Getting voice transitions right meant choosing a threading approach that waits properly — not cutting off too early and not hanging too long. I don't have the vocabulary to explain the technical choice my AI partners made, but I understand why it matters: without it, the app would talk over itself or go silent at the wrong moments. - SwiftUI kept destroying and recreating the audio managers at the worst possible moments. We built a centralized container to stop that. I didn't know the technical term for the problem, but I sure knew when the app stopped listening mid-conversation. About myself: - I can build real software. Not because I'm an engineer, but because I learned to collaborate with tools that extend what I can do. That's the whole premise of vibe coding, and it actually works. - The project I'm most proud of is also the one I haven't finished yet. And I think that's fine. This project embodies vibe coding as I understand it: human intention leading, AI amplifying, and engineering discipline holding the system together. Success for me is simple: Nana happily filling her long days with word games again. **Built with love, caffeine, and three AI assistants who all have names. **This submission was also written with AI help — Smudge and TARDIS helped me organize and articulate what I built. The ideas, the decisions, and the mistakes are mine. The polished sentences are a collaboration, just like the app itself. Relevant URLs GitHub repo: https://github.com/soylea-crowsnest/WordCoffeeBreak (submitting under two emails because I am not sure which profile is considered the purchasing profile)